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ABSTRACT 



DUDLEY KNOX LIBRARY 
NAVAL POSTGRADUATE SCHOOL 
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Restricted water transits by U. S. Navy ships require detailed planning by 
Commanding Officers, Navigators and the entire ship control watch team. The methodical 
maritime navigation planning process currently used has not changed appreciably since 
World War Two. The process remains a manual one, relying primarily on hard copy data 
(which is distributed via the U. S. Postal system or other Governmental shipping means) 
for updates to the navigation picture. The explosion of information sources and 
technology provides an opportunity to revolutionize the entire maritime navigation 
planning process. 

The thesis contains an overview of the current manual navigation planning process 
used by the U.S. Navy. Alternatives for migrating the current method to an automated 
process are explored. A requirements analysis is conducted to capture fleet navigator 
feedback for a prototype automated navigation planning tool. 

Conclusions drawn from this study are implemented in the prototype on-line 
navigation planning tool that has been dubbed “GatorNet.” Additionally, a requirements 
document is developed with the objective of shifting the maritime navigation planning and 
debriefing paradigm from a manual mindset to an automated one. 
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I. 



INTRODUCTION 



A. CURRENT FLEET NAVIGATION PLANNING AND SHORTFALLS 

Restricted water transits by naval ships require detailed planning by Commanding 
Officers, Navigators and the entire ship control watch team. Standardized navigation 
planning guidelines have been developed to improve safety and an extensive publication 
system provides the vast majority of information used in the planning process. Typically 
this information is dated and does not incorporate organized port visit and harbor transit 
feedback from the fleet. The planning process has evolved over many years, but the 
planning tools have changed very little. The explosion of information sources and 
technology provide an opportunity to revolutionize the entire navigation planning process. 

Great strides have been made in providing imagery intelligence through the Joint 
Deployable Information Sub-System (JDISS). Battle space awareness has been greatly 
improved using the Joint Maritime Command Information System (JMCIS) by fusing 
multiple C4I systems into a single tactical display. The Global Command and Control 
System (GCCS) has evolved and taken the fusion concept of JMCIS one step further, 
incorporating a UNIX based client server system of standardized relational databases. 
However, due to the low profile nature of “routine” navigation planning, a lesser effort 
has been made to use information technology to significantly improve this process. 

The shift in focus from blue water to littoral operations has increased near shore 
navigation operations. Ironically, this seemingly “routine” process provides one of the 
greatest safety risks during peacetime operations. During wartime operations when 
mining and near-shore hostile actions require even more precise navigation, there will be 
an exponential increase in the amount of required navigation planning. 

Naval ships safely transit dozens of harbors every day. Navigators plan and brief 
the transit using a library of hard copy publications designed to provide critical safety 
information. Occasionally, record messages written by ships that have “recently” made the 
transit lend valuable insight. Often the Commanding Officer and Navigator have no choice 
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but to rely heavily on the judgment of a paid pilot (who sometimes speaks broken English) 
to safely navigate foreign harbors. Quartermasters take visual bearings off radio towers, 
lights, and water tanks believed to be the proper navigation aid. Visual fixes are 
compared with Global Positioning System (GPS) measurements as the ship transits the 
harbor. As the ship approaches the dock, the Commanding Officer gets his first view of 
the pier, tugs and fittings. After a ship moors, all this information is debriefed in a matter 
of minutes and rarely, if ever, is any of this valuable information captured and passed on to 
the next ship that must make the transit. An objective of this thesis is to shift the 
navigation planning and debriefing paradigm from a manual mindset to an automated one. 

Just as with U. S. Navy Food Service, the surface navigation planning process has 
not changed appreciably since World War Two [Ref. 1], The process remains a manual 
one, relying primarily on hard copy data (which is distributed via the U. S. Postal system 
or other Governmental shipping means) for updates to the navigation picture. The 
explosion of information sources and technology has gone relatively unnoticed as viewed 
from the eyes of today’s U. S. Navy navigation planners. Distributing a relational 
database on CD-ROM and using the World Wide Web as a vehicle to rapidly provide up- 
to-date digital navigation planning information to fleet users shows great promise, and is 
supported by the fleet navigation planners (see Chapter II). 

B. FLEET NAVIGATION GUIDANCE AND INITIATIVES 

1. Navigation Guidance Provided by the Commanders, Naval Surface 
Forces, Naval Air Forces Atlantic and Pacific 

Standardized navigation planning guidelines have been developed to improve 
safety. In addition to the extensive publication system, the Commanders, Naval Surface 
Forces and Naval Air Forces, U. S. Pacific and Atlantic Fleets (CNSL/CNSPINST 
3530.4) Instruction provides the vast majority of guidance used in the planning process. 
Appendix A. is a comprehensive list of all navigation planning publications and products in 
use in the fleet today. 
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The Type Commander’s navigation guidance primarily focuses on. (a) The flow of 
navigation information from the Navigation Watch Team to users, (b) Maintaining 
proficiency in navigation skills, and (c) Emphasizing navigation precision, accuracy and 
responsibility. 

Although there is an acknowledgment in the Type Commander’s Instruction of the 
increasing complexity of ship operations, there is little guidance for applying information 
technology to help with navigation planning, other than a suggestion to Navigators to use 
the National Imagery and Mapping Agency (NIMA) Navigation Information Network 
(NAVINFONET). In short, the focus of the entire instruction is on management of the 
manual navigation process [Ref. 2], 

2. Navigation Sensor System Interface (NAVSSI) 

The Navigation Sensor System Interface (NAVSSI, AN/SSN-6) was installed and 
tested on USS YORKTOWN (CG-48) as a part of the Smart Ship Program. NAVSSI 
was established to fulfill Chief of Naval Operations (CNO) requirements to use and 
distribute GPS data as the primary source of navigation data [Ref. 2], NAVSSI contains 
the following functionality: 

• Provides an accurate and automated distribution of navigation data to the 
shipboard users. 

• Allows the ship’s Navigator and bridge crew to perform mission planning, 
underway voyage progress tracking, and formation steaming functions using 
Government Off-the Shelf (GOTS) software. 

• Distributes real-time, best available navigation data. 

• Provides data for use by strike warfare systems for GPS initialization. 

• Places control of navigation selection and distribution in the hands of the 
navigation team. 

• Provides the navigation team with a workstation for Battle Group navigation 
planning and monitoring. 
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• Provides a system to support safe navigation using digital nautical charts and 
chart tools, to meet Electronic Chart Distribution Information System (ECDIS) 
functionality. NAVSSI is beginning to be installed aboard fleet ships, and also 
has been introduced into navigation training at the Fleet Training Centers 
Atlantic and Pacific. 

3. NAVINFONET, NAVCEN, and MARILOG 

There are several U. S. Government and commercial tools and World Wide Web 
Sites that have been created to aid in Navigation Planning. NIMA maintains an American 
Standard Code for Information Interchange (ASCII) based bulletin board system called 
the NavInfoNet, or Navigation Information Network, to help provide timely navigation 
safety information to military and civilian mariners. By dialing up a 9600 baud phone line 
at NIMA, a user can obtain information such as Chart Corrections, Broadcast Warnings, 
Maritime Administration Advisories, List of Lights, Anti-shipping activity messages, and 
U. S. Coast Guard Light Lists. Although there is no charge for the use of the system, 
there are long-distance telephone charges involved, and this can be cost-prohibitive for the 
ship at sea using the expensive International Maritime Satellite (INMARSAT) single 
channel telephone system. Some ships have reported that they are not allotted enough 
phone lines to permit use of a single line for NavInfoNet. NIMA recognizes the shortfalls 
of this ASCII based system, and is currently upgrading it into a graphics based World 
Wide Web site, scheduled for implementation in October 1998 [Ref. 3]. 

There are other sources of navigation information that are available now on the 
World Wide Web, such as the Coast Guard’s Navigation Center web site called NAVCEN 
[Ref. 4], Some of the useful navigation information available at this site includes Local 
Notices to Mariners and navigation communications advisories for LORAN-C (Long- 
Range Navigation) and GPS. In addition, there are numerous other non-government 
navigation and marine safety web sites, such as the Institute of Navigation [Ref. 5] and 
MARILOG [Ref. 6] sites, which contain information such as safety advisories and 
advertisements on commercial navigation products. 
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4. The Computerized American Practical Navigator (Cap’n) 

The Computerized American Practical Navigator (Cap’n) is a commercial software 
navigation tool widely used on Naval Ships. Its functionality is broad, and navigators can 
use it to manage daily navigation chores including voyage planning and navigating with 
computer display electronic charts via GPS or celestial inputs [Ref. 7], Numerous other 
useful functions include tide and current predictions, set and drift calculation and 
automatic dead reckoning. Also, several large databases can be accessed through the tool 
including Aids to Navigation, NIMA and NOAA charts, undersea features and ports. 
Nautical Technologies, Ltd. distributed a demonstration version of this commercial 
software package to the fleet in 1994, and several hundred U.S. fleet ships have reported 
that they are using the program (see Chapter II). 

Although the usefulness of the Cap’n program is obvious, it has yet to be officially 
sanctioned and distributed by the U. S. Navy. In fact, NAVSSI is the Navy’s answer for 
electronic charting. One weakness of the Cap’n system is that it was designed to operate 
in a stand-alone mode, and not to be interfaced with the World Wide Web. Although it is 
a powerful tool and it continues to be improved, it is still not a single source system 
tailored for all of the Navy’s navigation planning needs. 

C. RELEVANT FLEET C4I INITIATIVES 

There are numerous Command, Control, Computer, Communication and 
Intelligence (C4I) initiatives underway by several federal agencies that to some extent or 
another are merging navigation with information technology. Many of these initiatives 
focus on using digitized nautical charts, improving navigation accuracy through use of 
Differential GPS (DGPS) or the Ring Laser Gyro Navigator (RLGN) inertial navigation 
system, and integrating these technologies into an information suite on the ship’s bridge. 
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Some of the leading Department of Defense C4I initiatives include: 



1. GCCS 

The Global Command and Control System (GCCS) is a “system of systems” which 
has replaced the Worldwide Military Command and Control System (WWMCCS) as the 
U. S. Joint command and control system. There are several GCCS applications that have 
tremendous relevance to the management of the surface navigation problem. Logistical 
information contained in key port databases, for example, permits planners to determine 
well in advance if a particular port can support a ship visit. These GCCS applications 
include: 



a) Airfields Databases via JOPES and DAFIF 

A Joint Operation Planning and Execution System (JOPES) application on 
airfields exists and is interfaced with GCCS. However, it is extremely difficult for a fleet 
user to access this database, as the application is only licensed by the Defense Information 
Systems Agency (DISA, the GCCS program manager) to ten Commander in Chief 
(CINC) level commands. NIMA also maintains the Digital Aeronautical Flight 
Information File (DAFEF). This database contains airport, runway, navigation aid, enroute 
and terminal data [19], 

b) Ports Database via GSORTS 

A Ports Database is available via the GCCS Status of Operational 
Readiness and Training Systems (GSORTS), and contains some useful information on 
potential ports of call. This information is similar to that available in the government’s 
Publication 150, the World Ports Index. 

c) Overlay management via COMPASS Middleware 

The Common Operational Modeling, Planning and Simulation Strategy 
(COMPASS) is an application of services interfaced with GCCS. This system permits 
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staff planners to model and simulate plans in a real-time, collaborative manner. Scenarios 
ranging from chemical warfare to amphibious assault can be tested to build insight into 
exercises and actual combat operations [Ref. 8], The system was designed to use real- 
world data to help planners evaluate the key decisions of an operation. COMPASS also 
contains some functionality that is useful for navigation planning, such as chart and map 
overlay capabilities. 

d) SIPRNET and NIPRNET 

The Secret Internet Protocol Router Network (SIPRNET) is the secret- 
level packet data portion of the Defense Information Systems Network. The backbone of 
SIPRNET is a DOD Wide Area Network (WAN) composed of an autonomous network 
of new hardware and software. SIPRNET is integrated with GCCS and allows users to 
transmit and receive classified data up to the Secret/Noforn level from a variety of 
subsystems and applications [Ref. 9:pp. 7-78], Concurrently, the unclassified but sensitive 
Internet Protocol Router Network (NIPRNET) uses commercial protocols to transport 
unclassified data over the Defense Information Systems Network. Both the SIPRNET 
and NIPRNET have been installed and are in worldwide use. These trusted conduits 
provide more than adequate potential for growth, and might include a prototype 
navigation planning Web site. 

2. Lessons Learned Database 

The U. S. Navy maintains an extensive database of ship, submarine, and squadron 
lessons learned via the Navy Lessons Learned DataBase (NLLDB). Fleet personnel 
created this library of corporate knowledge with message input using the Navy 
Instructional Input Program (NIIP) [Ref. 10]. The entire database is distributed quarterly 
by the Director, Navy Tactical Support Activity, in the form of CD-ROMs. This digitized 
information is a part of the Navy Tactical Information Compendium (NTIC) series “A.” A 
more thorough discussion of this system is contained in Chapter II, Section B. 
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3. Internet to Sea (SEANET) Program 

The SeaNet Project is a collaborative effort to bring the Internet to all fleet ships. 
The program was originated as an academic study at the Naval Postgraduate School in 
Monterey, California. There are many dimensions to the project, including global 
connectivity via future Low Earth Orbit satellite networks. The basic concept of 
widespread Internet access to ships at sea with healthy bandwidth resources is a 
cornerstone of the project [Ref. 11], The concept of using commercially available 
communications and protocols can also be applied to a prototype navigation Web Site. 

4. Gobal Broadcast Service 

The Global Broadcast Service (GBS) is a DOD application of commercially 
developed technology. The service consists of a network of high-powered satellites and 
small receive terminals. When the service is established in the near future, an exponential 
increase over current Satellite Communication (SATCOM) capability and bandwidth will 
result, due to the use of smaller antennas and higher data rates [Ref. 12], In short, this 
initiative is undergoing initial operational testing, and appears to be a promising means of 
increasing available bandwidth to fleet users. 

5. Information Technology for the 21 st Century (IT-21) 

Information Technology for the 21st Century (IT-21) is a Fleet Commander in 

Chief initiative to push all administrative and tactical computing business to desktop 

personal computers. The following excerpts from the Commander In Chief, U. S. Pacific 

Fleet’s vision, summarize the concept: 

A shift from platform centric warfare to network centric warfare; 
...principal elements of IT-21 are afloat LANs and ashore LAN/WANs 
populated by 'state-of-the-shelf personal computers which will integrate 
tactical and tactical support applications with connections to enhanced 
satellite systems and ashore networks. Furthermore, IT-21 is a 
philosophical C4ISR warfighting process transformation away from 
expensive, single-function workstations to affordable, highly capable 
personal computers. 
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In short, the IT-21 plan envisions that all naval computer business, both tactical 
and non-tactical, will be driven to a single, networked, desktop computer [Ref. 13], This 
movement has generated widespread support throughout the Navy, including the support 
of the Department of the Navy Chief Information Officer (DON CIO). One of the largest 
benefits this movement will bring to fleet navigators is a significant increase in the numbers 
of networked microcomputers available for both World Wide Web access and navigation 
planning. 

D. A NEW TARGET ARCHITECTURE 

Key to a new target navigation planning architecture’s success is accessibility by 
the navigation watch team and user friendliness. If the entire planning concept and 
feedback process becomes too difficult, the system will fail. A working solution to the 
manual navigation-planning problem is proposed in the form of a prototype Web Site. 
The tool has been developed and a Web site was used so that the fleet can immediately 
appreciate it. The current planning process has been thoroughly researched and detailed 
requirements from the fleet have been incorporated into GatorNet, the Navigator’s 
Planning Network. 

E. SUMMARY OF REMAINING CHAPTERS 

Chapter II describes the methodology used to design and disseminate a navigation 
survey to the fleet. The chapter presents data collected and analyzes user requirements 
and how they relate to ongoing initiatives. Alternative hardware platforms and 
technologies for a navigation planning system are explored in Chapter III. A discussion of 
automating traditionally manual navigation tasks is included. An overview of the 
GatorNet rapid prototype, a World Wide Web based navigation planning tool, is presented 
in Chapter IV. Functionality of the tool is discussed and design considerations are 
included. Software tools used to create the graphical user interface are explained in detail. 
A discussion of issues in implementing and integrating the prototype into the fleet is 
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presented in Chapter V. Finally, recommendations for further research and lessons learned 
are presented in Chapter VI. 
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II. REQUIREMENTS ANALYSIS 



A. FLEET SURVEY DESIGN 

1. Methodology 

To better understand the fleet’s requirements for navigation planning, the survey in 
Appendix B was distributed throughout the fleet. Due to the widely dispersed population, 
a survey was deemed the only feasible tool for data collection. It was used as an 
exploratory study to gauge overall opinion before giving the working prototype any 
specific direction. The total population of ships and staffs was known to be less than five 
hundred. Some of the groups that would be analyzed had a smaller population (i.e. 12 
CV/CVNs, 27 CG/CGNs, 24 mine warfare ships). Anticipating a return rate less than 
50%, it was necessary to survey the entire population to maintain statistical significance 
when looking at those smaller, groups. Since the survey was also meant to obtain new 
ideas, a population-wide survey was appropriate. 

In order to increase the return rate, a cover letter was included and the surveys 
were sent directly to the Commanding Officer. The desired respondent was the ship’s 
Navigator or staffs Navigation Plans Officer. It was requested that commands reproduce 
copies locally to obtain opinions of the Operations Officer, leading enlisted Quartermasters 
(QMs), and leading enlisted Operations Specialists (OSs). To encourage feedback yet 
allow group comparison, the survey maintained anonymity and collected the following 
demographics: 

• Rank 

• Title/Job Position 

• Time in Billet 

• Command 

• Command Status (ashore, deployment, work-ups, etc.) 
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To encourage further feedback, the survey was kept to the front and back of a 
single sheet of paper. Surveys are plentiful within the Navy and it was deemed important 
not to impose upon the fleet. The cover letter stated it should take no longer than ten 
minutes to complete the survey. 

Since many of the requirements to host an on-line system are not in the fleet, it was 
important to place a disclaimer at the top of the survey. The following note was included: 
Although you may not currently have access to the World Wide Web, please assume you 
have it or will have it in the near future when responding to these questions. Valid 
connectivity concerns and availability of computer hardware surfaced throughout the 
responses despite our effort. 

2. Survey Formulation 

A cross-section of open and close-ended questions was used on the survey. The 
open-ended questions were designed to answer the following questions: 

• How much did the fleet know about ongoing initiatives? What did they think 
of these initiatives? (Question 2) 

• What did the fleet think of the existing navigation planning system? Would 
they be willing to change from the existing publication system to a computer- 
based system? (Question 3) 

• What type of Navigation Lessons Learned were commands maintaining and 
how much importance did they place in lessons learned? (Question 4) 

• What computer hardware did users feel comfortable with? (Question 5) 

• What type of navigation planning information had been sought in the past that 
was important to include in a single data repository and possibly the prototype? 
(Question 7, Question 10, Question 14) 

• How could the existing navigation feedback systems be improved? (Question 
13) 

The closed-ended questions were designed to achieve the following: 
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• Where should we focus our prototype effort? (Question 6) 

• How useful is the existing Navy Tactical Information Compendium (NTIC) 
Lessons Learned System for Navigation planning? (Question 8) 

• How much time is spent correcting and maintaining navigation sources of 
information? (Question 9) 

• Which fleet and commercial systems are being used for navigation planning? 
(Question 11) 

In Question 6 a scale was provided to the respondents ranging from one (. Not 
Important) to five (Essential). The scale’s intervals were assumed equal to allow 
quantitative analysis. 

3. Data Grouping 

Since some ships sent more than one response (as requested), it was necessary to 
separate the data to keep multiple responses from influencing command specific questions. 
The entire set of data was initially grouped into two categories: all responses and one 
response per command. The all responses category was used to compare and contrast 
groups such as enlisted versus officer, time in position, or command types (i.e. ship versus 
sub responses). A junior quartermaster on a ship who took the time to fill out the survey 
had equal weighting with an executive officer of the same ship. The one response per 
command category was used to determine the number of ships using commercial products, 
the hours spent maintaining publications, or the type of lessons learned being maintained. 
The response that was chosen in the case of multiple responses per unit was the 
navigator’s or the job title of a respondent that came closest to that position. 

We formed a hypothesis that we might see a distinction in results among senior 
and junior personnel, Navigation and Operation departments, and platform size and types. 
Therefore, demographic data was collected to group results by job title, time in billet, 
rank, and ship type. When presenting the data, the groups in Table 2-1 are used. 
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Table 2-1 Group Compositions 



Group 


Ship Classes/Explanation 


Large Decks 


CVN, CV, LPH, LHD, LHA, LCC, MCS 


Small Boys 


CG,DD, DDG, PC, LPD, LSD, LST, MCM, MHC, PC 


Crudes 


CG, DD, DDG, FFG 


Amphibious 


LSD, LPD, LHD, LPH, LHA, LCC 


Auxiliary 


AGF, AGSS, ARS 


Logistics 


AE, AO, AOE, T-AFS, T-AO 


Mine Warfare 


MCM, MCS, MHC 


Submarines 


SSN, SSBN 


Junior Officers 


Ensign up to and including Lieutenant Commander 



B. PRESENTATION OF COLLECTED DATA 
1. Respondent Demographics 

Surveys were sent to 396 separate commands. 159 of the 396 commands 
responded for a return-rate of 40.2%. Due to multiple responses by several commands, 
238 total responses were received. Table 2-2 shows ship respondents by broad categories 
and percentages of their respective population. Table 2-3 shows similar data for staff 
responses. A consistent survey response rate of approximately 40% was achieved across 
all categories. 



Table 2-2 Ship Responses 



Category 


Responses 


Population 


Percentage 


Carriers (CV/CVN) 


6 


12 


50.0 


Cruisers (CG/CGN) 


12 


27 


44.4 


Destroyers(DD/DDG) 


21 


56 


37.5 


Frigates (FFG) 


16 


42 


38.1 


Amphibious 


13 


42 


31.0 
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Submarines 


30 


86 


34.9 


Mine Warfare 


10 


24 


41.7 


Patrol Craft (PC) 


5 


13 


38.5 


Logistics 


11 


18 


61.1 


Auxiliary 


7 


11 


63.6 


Total 


131 


331 


39.6 



As was expected, the majority of responses came from junior officers (0-1 through 
0-4) holding the job of Navigator between 12-36 months. Demographic data on 
individual respondents is shown in Figures 2-1 and 2-2. 



Table 2-3 Staff Responses 



Category 


Responses 


Population 


Percentage 


CARGRU 


4 


8 


50.0 


CRUDESGRU 


2 


6 


33.3 


SUBGRU 


5 


5 


100 


PHffiGRU 


0 


3 


0 


DESRON 


7 


17 


42.2 


SUBRON 


3 


10 


30 


PHIBRON 


4 


9 


44.4 


Total 


27 


63 


42.9 
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Appendix C contains summary information in numerical format. It is important to 
note that in Figure C-l of Appendix C, there is an overlap between the job title of 
Assistant Navigator (ANAV), Leading Petty Officer (LPO) and Leading Chief Petty 
Officer (LCPO). The numbers in the figure represent the titles as received on the survey, 
but in fact many LPO’s and most of the LCPO’s are also the ANAV. 



1 E-7 to E-9 
m <=E-6 

□ Second Officer* 

□ 0-1 to 0-3 

44 ■ 0-4 

1 05 and 0-6 
E Unknown 

♦2 nd Officers serve on Military Sealift Command vessels 

Figure 2-1 Response by Rank 




12 25 




a >36 
1 12 to 36 
□ < 12 

□ Not Specified 



Figure 2-2 Response by Months in Billet 



Although comparing and contrasting data from the various groups was not a 
primary concern, having the data grouped allowed us to test several hypotheses: 

• Were enlisted and officer opinions significantly different? 

• Did time in a job change opinions? 
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• How did navigator and quartermaster responses compare to operations related 
job positions? 

• Did ship type have an impact on results received? 

Each of these sub-groups was large enough to provide statistically significant information. 

2. Statistical Validity 

To allow valid inference about a population based on a sample, it is important that 
the principle of randomness be embodied in the sample selection procedure [Ref. 14:p. 
270], With our sample containing only the returned results there is some possible 
influence on the randomness of the sample. We assumed the US Postal Service was 100% 
reliable (in fact one response returned with an open envelope and no survey inside). It is 
presumed that commands that did not return the results could not find the time, lost the 
survey, or simply chose not to respond. For our purposes, we will assume one of the first 
two instances and therefore this principle of randomness is somewhat intact. Since the 
observation values are integers between one and five for Question 6, the population 
distribution is certainly not normal. However, thanks to the Central Limit Theorem 
whatever the common distribution of a set of independent random variables, provided that 
their variance is finite, the sum or average of a moderately large number of them will be a 
random variable with a distribution close to the normal [Ref 14:p. 207], 

To determine whether the samples statistically portray their respective population, 
several confidence intervals were computed for groups of varying sample sizes. Question 
6 of the survey provided guidance toward the features to be included in the prototype. 
The authors felt it would be useful to include pictures of aids to navigation so that prior to 
harbor transits, quartermasters could get a mental image of the aid. When shooting visual 
bearings, it is often difficult to correlate charted aids that have never been seen with actual 
navigation aids — especially if the surroundings have been built up due to construction or if 
more than one similar aid exists (i.e. multiple radio towers). A picture can eliminate any 
confusion and like the cliche it is worth a thousand words. Appendix D contains the 



17 



calculations for the statistics contained in Table 2-3 using the Picture responses on the 



survey. 



Table 2-4 Confic 


ence Intervals 


Group 


Sample Size 


Sample Mean / 


Confidence 


Computed Population 




(n) 


Std Dev (sj 


Interval 


Mean 


Amphibious 


13 


4.29/. 85 


95% 


3.78 < <4.80 


Amphibious 


13 




90% 


3.87 <g <4.71 


Amphibious 


13 




80% 


3.97 < (i < 4.61 


Navigators 


103 


4.19 / .71 


99% 


4.01 < g < 4.37 


Navigators 


103 




95% 


4.05 < p. < 4.33 


Navigators 


103 




90% 


4.08 < |i < 4.32 


All Respondents 


238 


4.10/. 94 


99% 


3.94 < (x < 4.26 


All Respondents 


238 




95% 


3.98 <n< 4.22 


All Respondents 


238 




90% 


4.00 < n < 4.20 



Observing the confidence intervals for the population means, even the smallest 
sample group of amphibious respondents provides a tight enough interval for our 
purposes. By relaxing the confidence to 80%, one can hypothesize that the entire 
population of amphibious ships (42) find having pictures included in the prototype 
important (4 on the scale of 1 - 5). 

The information obtained from the surveys follows by question number. In many 
of the tables, the two groups of responses are compared: All Respondents and One 
Response per Command. This is done to compare and contrast the Navigator/Navigation 
Plans Officer responses with all returned samples. 

3. Systems Hardware Results 



a) Question 3: Type of Planning System Desired 

The overwhelming majority (68%) of respondents stated they would prefer 
an online system compared to the current publication system (Table 2-5). “On-line” was 
not defined, but most respondents interpreted this as computerized and not necessarily 
connected to the Internet or a network. Many stated the “on-line” system would save 
space — notably Patrol Craft (PC), Mine Countermeasure Ships (MCM), and Submarines. 
On the other hand, these same individuals expressed concern for the availability of 
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computer assets. Typically, smaller ships have far less computer assets and less 
telecommunications connectivity capability. Many felt an online system could reduce their 
workload on correcting publications and charts. The 35 respondents who stated they 
wanted both an online and hard copy publication capability for the most part stated they 
did not trust an “online” source to have the reliability necessary for a navigation planning 
system. The 23 respondents who stated they wanted to maintain the current publication 
system primarily did not see the cost benefit of introducing a new system. Both the 
reliability and cost issues are valid and will be addressed in later chapters. There was very 
little difference between the two groups of information. The results are listed in the 
following table. 



Table 2-5 Question 3 Navigation Planning System 



Answer 


One 

Result/Command 


Percentage 


All 

Respondents 


Percentage 


Online 


112 


69 


160 


68 


Both 


23 


14 


35 


15 


Publication 


19 


12 


23 


10 


Neither 


3 


2 


5 


2 


No Response 


5 


• 3 


13 


5 



b) Question 5: Configuration for a Consolidated location or 
“Library” of electronic Navigation Information 

Question 5 was intended to gauge the willingness of individuals to embrace 
technology. It was also written in an intentionally ambiguous way using “configuration” 
so as not to influence the results toward a certain technology and to see what new ideas 
could be generated. It may have been too ambiguous since many respondents stated they 
did not understand what was meant by “configuration”. Many declined to answer the 
question (33% of all responses). Those that did answer overwhelmingly felt CD-ROM 
would be the medium of choice (Table 2-6). Not only are CD-ROMs a very logical choice 
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for a “library” of electronic information, but the National Imagery and Mapping Agency 
(NflVLA) is currently digitizing publications and distributing them on CD-ROM. Only a 
handful of publications (Sailing Directions, Port Directory etc.) have actually been 
introduced to the fleet, but this may have influenced the survey responses. This 
digitization is a start in the right direction, but is primarily aimed at paperwork reduction. 
An interactive program where all sources of information including graphics can be queried 
and searched would be more ideal. 

Ideas submitted for the Other category included updated disk distributed 
quarterly; user friendly; Navigation Sensor System Interface (NAVSSI) compatible; and 
JMCIS resident. 



Table 2-6 Question 5 Configuration 



Question 5 Results 


One 

Result/Command 


Percentage 


All 

Respondents 


Percentage 


CD-ROM 


58 


35 


82 


34 


WWW 


10 


6 


16 


7 


WWW/CD-ROM 


5 


3 


7 


3 


Online 


3 


2 


4 


2 


Other 


42 


25 


51 


21 


Blank Response 


47 


28 


78 


33 



4. Lessons Learned Results 



a) Question 4: Lessons Learned “ library ” Currently Maintained 

This question was intended to measure not only what commands 
maintained, but also gain insight on the value that they placed on lessons learned. The 
range of answers was quite broad from “none” to “binders containing information on each 
harbor transit.” The responses (Table 2-7) were grouped into the following categories: 
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None, Safety/Mishaps, Port Visits, Lessons Learned, Nav Briefs, and Other. None was 
only tallied if the command actually stated “none”. The rather broad category of Lessons 
Learned was marked if the command was not specific in their response but made any 
mention of maintaining some aspect of lessons such as message traffic. Had we asked 
them to mark boxes of the categories, more accurate data would have been collected. 
Unfortunately, by giving the categories to the respondents, we felt we might influence 
their answer — no command wants to admit they don’t maintain a file on safety messages, 
port visits or navigation details. With an open-ended question, the tradeoff was less 
accurate quantitative data, but there was less chance of simply “checking a box.” 

Types of lessons learned categorized as Other include: Collision briefs, 
Port Directory, Historical, Check rides, NTIC etc. If there is any conclusion to be drawn 
from question 4, it is that surprisingly few commands maintain a serious navigation lessons 
learned library. The fact that fully 25% stated None or did not respond and that no single 
category was above 38% shows considerable room for improvement. Although the 
formulation of the question may have reduced the results, many commands are seemingly 
reinventing the wheel. 



Table 2-7 Question 4 Lessons Learned Maintained 



Question 4 


Number Mentioned 


Percent of Commands 


None 


20 


12 


Safety/Mishap 


40 


24 


Port Visit 


60 


36 


Lessons Learned 


63 


38 


Navigation Briefs 


14 


8 


Other 


16 


11 


No Response 


21 


13 
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b) Question 8: Navy Tactical Information Compendium (NTIC) 

System 

The NTIC CD-ROMs are distributed quarterly to the fleet. They contain 
the Navy’s Lessons Learned System (NLLS) which was established in 1991. Before that, 
no formalized methodology for collecting and distributing lessons learned existed within 
the fleet. The initial focus was limited exclusively to operational issues that had proposed 
workarounds. This policy excluded substantial information in other areas during fleet 
operations and exercises. For the purpose of this system, a lesson learned is information 
expressly and specifically contributing to the value of the Navy’s established body of 
knowledge [Ref 10], To qualify as a lesson learned, an item must reflect “value added” to 
existing policy, organization, training, education, equipment, tactics, techniques or 
doctrine by identifying problems areas. The NLLS provides a responsive method for 
identifying deficiencies and initiating corrective actions. However, this approach reduces 
lesson learned information that could be derived from policies or doctrine that work and 
are not “problems”. Somebody preparing for a similar exercise or operation could gain 
confidence or insight into how successful policies or doctrine worked. In an effort to 
minimize the database and focus on correctable issues, the existing system excludes 
positive feedback. The secondary objective is to minimize the system’s cost by using a 
text-based database system to collate, evaluate and disseminate Navy-specific lessons 
learned. The system allows standard search queries for phrases or words. It is compatible 
with the Joint Universal Lessons Learned System [Ref. 15]. 

Although it is desired that all lessons learned gravitate toward this single 
system, the reality is that many navigation lessons learned in the fleet take the format of 
after action messages or inputs to the Port Directory Guide. Searching the NLLS reveals 
some navigation information, but far from a comprehensive database. The purpose of our 
asking question 8 was to test the fleet’s familiarity with the system as well as see if 
anybody was using it for exercises, transits, port visits or amphibious operations. The 
survey results indicate the system is a failure with respect to navigation. As shown in 
Table 2-8, fully 47% of the respondents have never even used the system and 36% more 
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use it less than once per month. Those using the system do not appear to use it for purely 
navigation related matters. Our survey respondents are the individuals who are supposed 
to submit the lessons learned. If they are not using the system to obtain lessons learned, 
this may indicate why so few navigation-related lessons learned exist within the system. 



Table 2-8 Navy Lessons Learned System 



Frequency NTIC Use 


Responses 


Percent 


Type of NTIC Use 


Responses 


Percent 


Never Used System 


112 


47 


Exercise 


38 


30 


Seldom (< 1/Month) 


85 


36 


Transit 


4 


3 


Regularly (> 1/Week) 


26 


11 


Port Visit 


12 


10 


No Responses 


14 


6 


Amphibious 


2 


2 








Exercise & Transit 


7 


6 








Transit & Port Visit 


14 


11 








Exercise & Port Visit 


14 


11 








Other Combinations 


13 


10 








Other Uses 


6 


5 








No Response 


15 


12 



c) Question 13: Capturing Fleet Feedback and Navigation Lessons 

Learned 

This question was intended to generate ideas on how to best improve the 
existing lessons learned process. The Fleet Intel Collection Manual (FICM)/ONI requires 
a Port Visit Report to be completed by select ships after foreign port visits [Ref. 16]. This 
report contains useful logistic and navigation information, but the enforcement of the 
report and redistribution of information to the fleet navigator is lacking [Ref. 17], The 
current methods of after action messages, Port Directory inputs, FICM reports, and the 
NLLS are designed to provide only qualitative information. No system is in place to 
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actually collect data and generate quantitative results. For example, a simple formatted 
survey could be constructed that required navigators to rank the pilots, tugs, navigation 
aids, currents, pier fittings or other aspects of the navigation detail. Survey questions 
could also collect qualitative commentary. A ship preparing for a foreign harbor transit 
could query the database by ship class, timeframe, or response type. This would provide 
considerably more information in preparing for the transit, and allow greater insight into 
what to expect. Since we envisioned building such a port survey into the prototype, we 
didn’t want to influence the respondents and used an open-ended question to generate 
new ideas. 

The responses were quite varied and ranged from “can’t be done” to 
“establish a required format.” Many brought up interesting points like how do you 
validate the data or prevent misinformation. Some saw this as an added burden and felt 
the system was already in place. The consensus felt a required, formatted survey would 
work that was sent to a central database. They mentioned surveys could be uploaded at 
the earliest opportunity via e-mail or via the WWW. A creative response mentioned a web 
site could list critical information that was lacking and needed to populate the database. It 
was difficult to quantify this open-ended question. In general, the positive responses far 
outweighed the negative, which indicated people saw a need for an improved system. The 
results of question 13 are in Appendix E. 

5. Prototype Information Results 

a) Question 6: Importance of Navigation Information Sources 

To aid in the design of the prototype, question 6 gave the respondents a 
chance to tell us how important different types of information would be if accessible in a 
single location (system). It gave us a chance to test what we felt was important to include 
against the fleet’s requirements Since the prototype would not contain all information, it 
also helped us focus our efforts on what the fleet found most important. Using the 
demographic data, this question provided a potential wealth of statistical and grouping 
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analysis. When comparing groups of responses throughout question 6, what actually 
stands out is how little difference truly exists. 

Due to the large number of graphs obtained from this question, they have 
been grouped together in Appendix F. Graphs F-l and F-2 provide a visual depiction of 
how respondents answered on the scale of 1 (Not Important) to 5 (Very Important). 
Graph F-l is for all respondents and F-2 is the One Response/Command group. There is 
very little difference between the two graphs. The same data grouped by percentages is 
included in graphs F-3 and F-4. What is obvious from these four graphs is the relative 
importance placed on the categories of information: 

• Port, Meteorological and Safety data were all ranked Very Important by over 
50% of the respondents. Over 90% of the respondents ranked Port and 
Meteorological data Important or Very Important. 

• Over 85% of the respondents ranked Pictures, Lessons Learned, and Safety as 
Important or Very Important. 

• Digital Pubs and Digital Charts received very similar support with 79% ranking 
them Important or Very Important. 

• Exercise and Imagery data followed with decreasing support and more 
dispersed answers. 

• Amphibious data received the least support but this is likely due to the small 
number of ships that directly participate in these operations. 

Each of the remaining graphs in Appendix F compare demographic groups 
and provides the average response, the standard deviation, and the mode. These three 
statistics are provided to allow full interpretation of the data. To begin the group analysis, 
Graph F-5 was constructed to compare every sub-group and uncover significant 
anomalies. The lines between data points are insignificant, but leaving them in the graphs 
aids in seeing trends and finding specific data points within tight groups of data. 

When observing the data, several questions can be asked. How far out 
must a sample group lie to be significant? More to the point, does it matter whether large 
deck ships think safety is .5 higher on the scale than the remainder of the groups? The 
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deck ships think safety is .5 higher on the scale than the remainder of the groups? The 
statistical formulas exist to test for the difference between population means, but the 
results did not prove tremendously useful. What was more interesting and insightful was 
to construct several graphs comparing logical groups, observe the data trends, and 
interpret the suggested results. The Navy is an organization full of communities rich in 
heritage. The greatest value of breaking the data into groups may likely be the ability of 
the reader to see how “their community” answered. 

Graph F-5 illustrates the strong support by all groups for the various types 
of information. As expected, amphibious ships ranked the amphibious data between 
Important and Very Important. Submariners who rarely operate in that regime gave that 
category the lowest mark. Graph F-6 shows Ship versus Sub versus Staff responses. The 
data suggests staffs find digital pubs, imagery, amphibious and exercise data more 
important than submariners do with ships falling in-between. This correlates with each of 
these groups’ special needs to conduct their primary missions. All three groups were in 
very close agreement with the importance of pictures, lessons learned, safety and port 
data. Graph F-7 further broke down the commands by specifying ship types. In addition 
to the amphibious data as mentioned before, large deck ships stand out on the importance 
of safety data. Graph F-8 compares big deck ships with small boys. Many small boys 
had mentioned the space saving convenience of digitizing pubs in the open-ended 
questions. The data contained in this graph supports this notion. 

The next series of groups compared job titles and ranks. Graph F-9 
compares Operations Officers with Navigators. Very few differences exist except to note 
that Navigators find pictures more important (they of course would primarily be the ones 
using them) and Operations Officers find amphibious and exercise data more important. 
Graph F-10 tried to show difference based on time within the job. Nothing particularly 
significant stood out. Graph F-ll broke the results out by rank of the respondent. The 
data suggests the young quartermaster out shooting navigation aids find pictures more 
important than the senior enlisted who has done it “the hard way” throughout his career. 
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Similarly, the E-6 and below who must maintain and retrieve a publication from the chart 
room found digital pubs more important than the Lieutenant Commander and above who 
may on occasion read the publication. There was a perplexing and sizable spread (.7) 
with respect to exercise data between E-6 and below ranking it the highest and 0-4 and 
above the lowest. Once again, the value added by grouping the data and comparing may 
be nothing more than an appreciation for sub-cultures within the Navy. The significant 
result to take away from question 6 is the fact that the vast majority of individuals place a 
high level of importance in almost every one of these categories. 

b) Question 7, 10 & 14: Additional Data Sources Desired, Missing 
Information Obtained from Other Commands, and Comments 
and Suggestions 

These three questions were open-ended with the intent of obtaining the 
overlooked or original idea. Many terrific ideas were obtained and Appendix E contains 
the vast majority of them. The following short list provides a sample of suggestions to 
include in a planning system: 

• Harbor regulations, Bridge to Bridge channel information, Vessel Traffic 
Scheme manuals 

• Quality of Navigation aids used for head bearings and drop bearings when 
anchoring 

• Sanitized Navigation Mishap Reports and Lessons Learned for Training 
Evolutions 

• Schedules Database for CINCLANTFLT or CINCPACFLT 

• Oil Rigs, Fishing Areas and Merchant Shipping Lanes 

• Amphibious Beach Surveys 

• Feedback section for inaccuracies found in existing publications 

• Foreign Charts and Publications (such as British Admiralty Charts) 

• Husbanding Agent e-mail addresses and phone numbers 
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6. Existing Navigation Tools 



a) Question 11: Current Systems in Use for Navigation Planning 

There are many systems that can be used for voyage planning, computing 
sunrise/sunset or plotting tides and currents. Most of them are commercial products that 
must be purchased out of the ship’s budget. This question was included to gain insight 
into what is already being used in the fleet. The results were quite interesting. 107 
Commands marked that they used a commercial product. Sixty or 56% of the commands 
are using a commercial software program called the Cap’n which contains many features 
for voyage planning, electronic charting, chart inventory, celestial computations and tides 
and currents (Chapter I). It is designed to operate on a desktop PC. Having used an 
earlier version of the Cap’n as a Navigator for voyage planning, it was easy to understand 
the timesaving that could be achieved. Purchasing electronic charting capabilities can be 
prohibitively expensive for individual ships and we did not measure how many 
commands have actually purchased this feature. The Navy’s current development of 
NAVSSI, which is slowly being installed on ships and recently introduced in the 
Navigation Schoolhouses in July 1997 [Ref 18], will provide many similar features of the 
Cap’n product. A comparison of the two products would make for an interesting study of 
Commercial Off-the-Shelf (COTS) software technology. 

There was no other commercial product mentioned with such frequency. 
Stella is a celestial computation software that is freely distributed to ships (may not have 
been considered a commercial product by many respondents) and received the next 
highest response rate with 13. Other products that received mention include: Navtrek (1), 
Micronautics (1), Tru-Chart (1), Sperry ECDIS (3), Chart Nav (1), Waypoint for 
Windows (2), and various tides and current programs. 

Access to GCCS, JDISS, and WWW systems onboard ship is currently 
limited to the upper level staffs and large deck platforms. It is not surprising that these 
systems were not marked more frequently. The results are contained in Table 2-9. 
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Table 2- 9 Systems Used for Navigation Planning 



System 


GCCS 


WWW 


JDISS 


Commercial 


Used 


9 


25 


14 


107 


No Response 


153 


138 


148 


55 



b) Question 9: Time Spent Maintaining and Correcting Hardcopy 

Materials 

To ensure safety of navigation, publications and charts require continuous 
maintenance as weekly changes are announced (Notice to Mariners and Local Notice to 
Mariners). A set of charts and publications used regularly must always be kept up to date 
[Ref. 18]. Charts and publications that are maintained in inventory for an overseas 
deployment or that are rarely used will have a Chart Card associated with them. The card 
will be “charged” or annotated if an outstanding correction must be made before use. 
Much of the quartermaster’s time is spent conducting this necessary maintenance. This 
extremely labor intensive process requires meticulous attention and can be susceptible to 
human error. Until a system can be devised that provides standardized, automatic 
electronic corrections little will change. A conceptual system might have publications on 
CD-ROM with a “Correction Database” cross-checked before the information is 
presented. This “Correction Database” could be in the form of a 3 -Vi inch diskette mailed 
weekly or a download from an online update. 

This question was included for completeness and as an opportunity to 
gather fleet wide statistics. If the process could be automated, significant man-hours 
could be saved. Another advantage would be reduction of errors. The standard deviations 
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of the results in Table 2-10 were extremely high. This can be partially attributed to the 
variety of operating environments and partially to the difficulty in Navigators accurately 
estimating or averaging these tasks. This data is not typically maintained or tracked by 
Navigators, although mapping this process may uncover some interesting results. 



Table 2-10 Weekly Maintenance Hours 



Question 9 


Hydro and HOT AM 

Files 


Nav 

Publications 


Nav Charts 


Other 


Hours 


4.4 


7.2 


12.1 


10.9 


Standard 


4.4 


7.1 


14.2 


8.4 


Deviation 











C. REQUIREMENTS VERSUS ONGOING INITIATIVES 

There are several initiatives that are underway to improve navigation within the 
fleet. The most notable is Navigation Sensor System Interface (NAVSSI), which 
provides electronic charting tools, voyage planning, and integration with GPS and other 
navigation sources. Publications are also being digitized and distributed on CD-ROM by 
NIMA. The Navy Lessons Learned System exists, but it is underutilized by the 
navigation community. Designed to be a low cost, low maintenance system, it does not 
provide the search tools, graphics or data capable in today’s information age. Since this 
initiative to digitize is well underway by NIMA [Ref. 19], the focus of our research has 
been on filling the information void for Navigation Planning. Ideally, the data gained 
from the users in this survey will help shape the future collection and dissemination of 
navigation information. 

Every idea mentioned within the surveys is technologically feasible. The fleet is 
willing to embrace a better system. The primary challenge for the remainder of this thesis 
is to develop a system recommendation that maximizes data interchange while 
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minimizing development and maintenance costs. The secondary challenge is to make it 
simple so that it gets used. The third and final challenge is to make it compatible with 
existing systems so it is not yet another stovepipe. 

D. SUMMARY OF REQUIREMENTS ANALYSIS 

Many of the responses included typewritten letters, provided literature on 
commercial products or named points of contact for further research. The overall quality 
and quantity of data returned exceeded our expectations. Although we envisioned 
conducting comprehensive statistical analysis comparing groups of data, the large sample 
sizes and consistency across groups negated much of the statistical analysis. Conducting 
the survey and interpreting the vast quantity of information provided the following 
tangible benefits: 

• Validated many assumptions 

• Allowed user input into system development 

• Provided direction for a new prototype navigation planning tool 

• Showed how willing the fleet is to embrace new technology 

It also may provide the intangible benefit of improving future acceptance and use of a 
new Navigation Planning System should it get introduced to the fleet. 

Taking into account the survey results, a system architecture that meets the needs 
of the fleet would contain two overlapping systems: 

• A relational database updated with current information and distributed to the 
fleet periodically (quarterly) on CD-ROM. Monthly diskettes could be 
distributed with information deemed critical. 

• A Client-server architecture with the most current database on the server to 
allow clients access to the newest information through a browser. Last 
updated dates could be used liberally to minimize connectivity times for ships 
at sea. 

An absolute key to making this database concept successful is obtaining quality inputs 
from the fleet. Formatted surveys to capture feedback would be an integral part of the 
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database. This data along with digitized pictures could be sent via diskette or 
electronically uploaded when feasible. With IT-21 mandating Office ’97 as the software 
of choice [Ref. 13], Access was chosen for our prototype database. IT-21 also solves the 
need for personal computers with more than enough power to run such an application. 
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III. MIGRATION ALTERNATIVES FOR A NAVIGATION PLANNING 

SYSTEM 

A. DEVELOPING ALTERNATIVES 

Migrating from the current manual navigation planning method to an automated 
method should be done carefully. The current repository of data and the process of 
collecting maritime navigation information in the form of hard copy charts, publications, 
updates, and computer products has evolved in the U. S. Navy over two centuries. In this 
chapter several different migration paths (manual to automated) will be explored, and 
some of the key pros and cons of the options will be weighed. Fleet users, in one form or 
another, suggested all migration options (Appendix E). 

The current manual method of navigation planning (described in Chapter I) has its 
greatest strength in that it is accurate and reliable. U.S. Government agencies that collect, 
produce, and disseminate navigation information are well established and have spent 
many decades developing the know-how and infrastructure to accomplish their mission. 
The greatest weakness of current navigation planning is that it is extremely labor 
intensive. According to fleet users, the average “unit” (e.g., ship, submarine, or afloat 
staff) spends nearly 35 man hours per week keeping their hard-copy navigation products 
(charts and publications) corrected and up-to-date (Chapter II Table 2-10). When ships 
are operating at sea, many more additional hours are spent collecting and filtering this up- 
to-date navigation data into informative navigation plans and briefs. Alternatives 
therefore should be developed to use state of the art computer technology to help reduce 
the number of man-hours being spent by fleet units on the maintenance and assembly of 
navigation information. 

A broad range of naval personnel, ranging from Navy captains (pay grade 0-6) to 
third class petty officers (pay grade E-4) provided the fleet survey feedback discussed in 
Chapter II. Based upon this fleet feedback, there is overwhelming support for migrating 
from the current cumbersome manual navigation planning process to a more efficient 
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automated method (Appendix E). This need to “digitize” all aspects of navigation is also 
well recognized by NIMA, and has been clearly articulated in their publication entitled 
Digitizing the Future. In addition, a new navigation demonstration software package 
called the Full Utility Navigation Demonstration (FUND) has just been released by 
NIMA in December 1997. This program reportedly accepts digital nautical charts and has 
some voyage planning capability [Ref. 20]. 

B. TECHNOLOGY OPTIONS 

Several ship navigation programs, both military and commercial, already exist in 
the fleet, as described earlier. The key functionality which should be added to current 
voyage planning tools is the ability to instantly access and accept any and all structured 
and unstructured digital navigation products, ranging from nautical charts to publications 
to database information. 

The following existing computer technologies are appropriate for these tasks: 

1. Computer Hard-Drive Resident Program 

The Naval Sea Systems Command (NAVSEA) Navigation Sensor System 
Interface (NAVSSI), described earlier, is an example of a navigation program designed to 
permanently reside on a shipboard computer hard-drive. NAVSSI was designed as a 
software layer to ride on top of the Joint Maritime Communications Information System. 
JCMIS runs aboard ship on the NAVSEA TAC-3 or TAC-4 computer workstation, which 
uses the UNIX operating system. Other hard-drive resident navigation programs are 
designed for personal computers, such as the Cap’n program. 

All hard-drive resident programs can operate in a stand-alone mode on a single 
computer, and many are designed to be accessed and used remotely via distributed 
computer networks and client-server configurations. 

The benefits of maintaining a navigation program on the local hard drive include 
[Ref. 21]: 
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If the computer network suffers a casualty, it can still operate in stand-alone 
mode on the local platform until the network is restored. 



• The security of the program and data may be enhanced if robust security 
features and access controls are maintained on a “local” computer (and not 
across the entire network). 

• Better control over standardization of software can be accomplished with 
hard-drive resident programs versus Intranet or Internet available programs, 
which may have many hundreds or thousands of users. Current rigid U. S. 
Navy version control and distribution of IT-21 compliant software helps to 
support the concept of standardization [Ref. 13]. 

The disadvantages of a Hard-Drive resident Navigation program and data include 
[Ref. 21]: 

• Islands of information - different platform capabilities 

• Possible multiple data formats - hard to share data 

• Multiple interfaces 

• Multiple protocols 

• Support costs for each platform/station 



2. Removable Media Updates to Hard-Drive Resident Programs 

Any hard drive resident navigation program must have some means of updating or 
revising both the operating program and the navigation data used. This is necessary 
because navigation data is often inherently perishable, and software is always being 
improved. For example, a meteorological phenomenon such as a tropical storm might 
completely change the characteristics of a Caribbean port’s ship berths. Storm-driven 
silting may occur in some areas of the inner harbor, and this condition would need to be 
immediately promulgated to potential visitors to the port. A “Notice to Mariners” 
(NOTAM) message would currently be broadcast to the fleet to inform ships of the silted 
harbor hazard. In addition, the storm may cause other long-term changes to the port and 
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services available there which may affect navigational publications covering the region. 
Herein lies the need to be able to update the navigational data resident on a computer hard 
drive, which may include charts and port publications for our example Caribbean port. 

One method of updating the hard drive would be to distribute a floppy disk update 
to the appropriate ships. The standard 3-1/2 inch floppy disk is removable and may 
contain up to 1.44 megabytes (Mb) of data after formatting. Other removable storage 
media which could be used for updates include the 3.5 inch zip drive, which can store 100 
Mb of data, and the 4.75 inch ISO 9000 format Compact Disk (CD), which can store up 
to 660 Mb of data [Ref. 22:p. 130]. All of these portable storage devices would have to be 
mailed or otherwise shipped to an afloat command to periodically update navigation 
software and data. Fleet feedback has indicated that such updates should occur anywhere 
from monthly to annually, with quarterly revisions being the most common 
recommendation for routine, non-emergency updates. 

CD optical disk technology has become popular in the 1990s, because it is 
inexpensive and so well suited for storing massive amounts of data. CDs were designed 
to store encoded digital information, such as up to 100,000 pages of text [Ref. 23:p. 101]. 
This is over 400 times the 3.5-inch high-density floppy disk storage capability. In 
addition, plastic CDs have other advantages over floppy disks: they are less vulnerable to 
magnetism, dirt, or rough handling [Ref. 22:p. 131]. Several different forms of CDs exist. 
CD-Read Only Memory (CD-ROM) is the most common and is intended for mass 
distribution of data. Other forms of CD technology include CD recordable (CD-R) which 
are write once, read many and CD read-writeable (CD-RW) which have the same 
functionality as floppy disks. CD Optical jukeboxes are a new innovation, which offer an 
inexpensive way to archive huge amounts of data with interchangeable libraries of 
stacked CDs. 
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3. 



World Wide Web or “Online” System 



Yet another automated migration alternative might be to make the navigation 
planning program and data available through a large computer network such as an 
intranet or the Internet. By taking advantage of a distributed computing environment and 
a client-server architecture, any number of fleet users could conceivably capitalize on the 
information “power” available from a modem World Wide Web navigation tool, for 
example. Updates could be rapidly transmitted over a network to a large number of 
users, thereby eliminating shipping costs and getting the information to users much faster. 

Other advantages of a Web-based Navigation Program and data [Ref. 22: pp. 4-5]: 

• Platform independence 

• Multiple data formats can be accommodated 

• Single interface 

• Uses common protocols 

• Easier to disseminate and share information 

• Minimizes ongoing support costs 

• Permits leveraging scarce computing resources 

C. OTHER ISSUES WITH A WEB-BASED NAVIGATION PROGRAM 

1. Bandwidth 

Any computer networks designed for use at sea must be designed with bandwidth 
in mind. Due to the inherently mobile nature of sea-based forces, satellite and long-haul 
radio links must be employed for information exchange. Appropriate radio frequency 
bandwidth must be allocated within the available spectrum to support the transmission 
and reception of massive amounts of data. 

In addition to bandwidth availability, the information capacity of the system is an 
important design consideration. The current typical “low-end” at-sea computer network 
has a T1 bit rate: 1.544 Megabits per second (MBPS) [Ref. 24]. This is being improved 
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as new initiatives to increase capacity are integrated into the fleet such as the Automated 
Digital Network System (ADNS). 

2. System Security and Data Vulnerability 

Networked computer resources and data have an inherently increased risk of 
corruption and unauthorized access due to the large number of users who have access to 
the network at any given time. A stand-alone personal computer typically has fewer 
users with access to it and therefore has a lower associated security risk. The current 
manual hard-copy navigation planning data also has fewer users who have direct access 
to it than if this same data were digitized and made available to the masses on a large 
network. Although the vast majority of navigation planning software and data is 
unclassified (with much of it commercially available or in the public domain) there exists 
a significant data vulnerability issue. If this unclassified navigation data were placed in an 
open database and made available to the public via the World Wide Web (WWW), a 
computer “hacker” might gain access to the database and alter critical information. For 
example, a chart that shows a reef near a port entrance could be modified to delete the 
reef and show safe water in its place. An unsuspecting mariner might access this 
corrupted data and use it in good faith to navigate into port, subsequently running 
aground on the “ghost” reef. This example illustrates that although navigation 
information is wholly unclassified, the database or other data sources must be protected to 
prevent unauthorized access or malicious tampering. The safety of marine navigation 
would therefore largely depend upon the strength of the database security features. At a 
minimum, the data source (database) should be designed with appropriate computer 
security features such as robust encryption (to protect the data) and password protection 
to validate authorized users to the system. The ideal system would also include a secure 
computer network to permit safe data transmission and reception. If the system were to 
migrate to the SIPRNET or NIPRNET, the security and password schemes used by 
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similar applications on those networks would be sufficient for a full-scale fleet version of 
GatorNet. 

3. Connectivity 

Numerous fleet users expressed a concern that a Web-based navigation-planning 
tool would not be available to them because they do not currently possess the needed 
telephone lines, personal computers, or network access necessary to support such a tool 
(Appendix E). Fortunately, the move to bring the Internet and more networked computer 
resources to sea has begun, as evidenced by initiatives such as SeaNet, IT-21, and ADNS, 
among others. The newest surface ship classes such as the DDG-51 and LHD-1 are being 
built with high capacity computer networks, although this does not solve the submarine’s 
connectivity problem while submerged. This may be the strongest argument yet to 
design any navigation migration system so that all needed data and software is contained 
onboard (locally), such as with the CD jukebox method. Periodic updates could still be 
sent via an outside network, which a submarine could access for updates when it is 
surfaced. 

D. SUMMARY 

A significant benefit of using network technology in conjunction with databases 
and other incompatible data formats is that a common interface can be achieved for 
multiple heterogeneous platforms [Ref. 25]. This is the beauty of such an arrangement: 
Vast quantities of distributed information can be “pulled” by a user into a single, easy to 
use Web interface. The benefits of using Web and database technology can be 
summarized as follows: 

The recent popularity of the World Wide Web has created a massive 
increase in both the supply and demand of Web-based technologies. 
However, the HyperText Markup Language used to construct the Web has 
limitations that challenge information content providers who want to 
supply current, up-to-date information with minimal administrative 
overhead. A powerful, extensible solution to many of these challenges is 
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the use of a database as a back end, or data source, for Web applications. 
Combining the Web with a database maximizes the strengths of its 
components. From the Web perspective, this combination offers user 
friendliness, cross-platform compatibility, and high-speed prototyping 
capabilities. From the database perspective, it offers relational data 
manipulation, high-speed search capabilities, and industrial grade data 
input and retrieval [Ref. 26]. 

This migration path was chosen for the GatorNet prototype development. 
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IV. 



“GATORNET” RAPID PROTOTYPE 



In order to prove the “GatorNet” concept, a rapid prototype was developed to 
demonstrate functionality and design possibilities. Although the World Wide Web 
(WWW) may not be the medium of choice for the final product, it allowed a convenient 
means to provide quick exposure of the prototype to decision-makers and achieve 
widespread visibility with Navigators throughout the Navy. The WWW also provides the 
perfect forum to easily distribute the prototype to widely disbursed clients and gather 
feedback for improvement. With these benefits in mind, a web based application was 
chosen for the prototype with the understanding that distributed CD-ROMs may prove 
more cost effective for the actual system until bandwidth, security, connectivity and 
standardization issues are resolved. These issues will be addressed in the following 
chapter. 

A. PROTOTYPE OVERVIEW AND GOALS 

Several areas were identified from the fleet survey as being candidates for proof 
of concept within the prototype. To manage the scope of the prototype, three primary 
areas were chosen. The first was visually depicting aids to navigation and harbors since it 
exploits a new concept that does not readily and widely exist in current planning. The 
second was developing a Navigation Lessons Learned Database that allows quick and 
easy access with more functionality than the existing NTIC CD-ROM or Port Directory 
publication systems. The third was creating port specific web pages that can be used to 
gather and disseminate timely information. To educate the user on the purpose behind 
“GatorNet”, survey results and thesis chapters were made accessible on the prototype site. 
Links to other navigation related sites were also included. 

San Diego, California was chosen as the primary harbor for data collection. As 
the largest naval homeport on the West Coast, it provides a familiar example to a large 
number of potential users. San Diego also provides a rich number of aids to navigation. 
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The true value of “GatorNet”, however, is providing a wealth of information on a port 
not yet visited by the navigator. 

1. Visual Depiction of Navigation Aids and Harbors 

With the advent of Differential Global Positioning Systems (DGPS) on each coast 
of the United States, an argument could be made that the accuracy of this system (within 
meters) will one day make traditional visual navigation procedures (triangulation through 
lines of position) obsolete. With less than 100 percent reliability and less than total 
coverage throughout the world’s harbors, that day is well into the future. Given that 
visual navigation will be required to guarantee the safety of our ships, it stands to reason 
that a better prepared navigation team is less likely to hazard the ship and its crew. 
Preparation can come in many forms. Historically, the navigation team researches 
restricted water transits in publications such as the Port Directory, Sailing Directions 
(foreign ports), Coast Pilots (US ports), Fleet Guides (approximately 15 highly visited 
Naval Ports), and through pertinent message traffic. 

Several of the publications contain aerial photographs for the larger ports to give 
an overview of the harbor layout. Occasionally they depict a primary navigation aid such 
as range markers to the main channel or a lighthouse. A thorough repository that includes 
pictures of multiple navigation aids that have been successfully used by other ships would 
allow the team to better plan and preview their transit. In addition, comments by 
navigators on aids that may appear useful on a chart yet are difficult to acquire could 
greatly assist the team. Imagine having a brand new seaman shooting lines of position 
for a Commanding Officer and Navigator’s first visit into the busy port of Hong Kong. 
The chance of locating and providing a timely bearing are increased tremendously if that 
seaman has a chance to view photos of the navigation aids prior to making the transit. 

Still pictures were chosen for the prototype due to storage and bandwidth 
considerations. Several pixel dimension and JPEG compression factor combinations were 
experimented with to produce a good quality picture while minimizing file size. The 
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primary goal was to keep the file size to 15Kb to minimize user download time. With a 
JPEG quality factor of 100 (Corel Photo-Paint’s scale ranges from 2-High to 255-Low), 
the color pictures used throughout the prototype averaged 10- 15Kb (image size 
approximately 3x5 inches on screen with 800 x 600 resolution). Several pictures were 
cropped with smaller dimensions depending on the navigation aid’s size and 
characteristics to further reduce file size. The pictures were taken with a 35mm camera, 
scanned into Corel Photo-Paint and sharpened ten percent to show greater detail. When 
developing the web pages, keeping the total page size less than 20K resulted in a 
reasonable page transfer time of less than ten seconds given a meager 2K/sec-transfer rate 
that is typically experienced through a remote access modem connection. If the ultimate 
GatorNet product were to include archives of photographs on a periodically distributed 
CD-ROM, larger and higher quality pictures could be included. Pictures available 
“online” could be limited to urgent ones dealing with safety issues, corrections to existing 
pictures, or those that are deemed crucial and add significant clarity to a confusing 
navigation aid. 

2. Lessons Learned 

As evidenced in the survey results, only 36% of the commands surveyed maintain 
organized lessons learned files on port visits. With a navigator holding the position 
usually less than two years, there is considerable “corporate knowledge” that is lost. By 
improving the method for collection and increasing the repository of information 
available to the navigation team, this knowledge can be captured and overall safety 
improved. 

In designing the GatorNet lessons learned applications, the following 
improvements were desired: 

• Increased volume of lessons 

• Quicker turnaround of information and easier access 

• Capturing author information and establishing a user database to enable 
contact through e-mail for future amplification should users have questions 
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• Quantitative orientation to provide precise, measurable data points for users 

• Graphic orientation and the ability to correlate lessons with photographs 

Searching the entire unclassified October 1997 NTIC Series A CD-ROM yields 

less than ten robust port visit lessons dating back through early 1996. The NLLS Fleet 
Management Sites (FLTCINCS, CINCUSNAVEUR, and COMUSNAVCENT) validate 
new lessons and review the database for currency and adequacy. Lessons are 
automatically expunged from the database after two years unless revalidated by the 
Management Site. Several smaller ports are not visited with great frequency, and 
although desired, ships are not always required to submit a lesson learned. Due to Secret 
classifications, the NTIC CD-ROMS usually reside within the Intelligence spaces on a 
ship and are not easily quickly accessible by the standard user. This combination 
produces the sparse number of navigation lessons present in the current system. Survey 
results demonstrated that the system is a complete failure with respect to navigation (47% 
of respondents had never used the system and 36% use it less than once a month). 

The Port Directory contains reports from ships on virtually every port visited by 
naval ships, but many are very dated and the reports are exclusively text oriented. Ships 
are periodically tasked to provide a report to update the directory. The reports are 
cumbersome and require inputs from several departments throughout the ship. Typically 
no feedback is received and new reports are not incorporated until the annual update. By 
providing users standardized forms (GatorNet uses a modified and scaled down version 
of the submission form for the Port Directory) that are simple to complete, the concept is 
to capture as many value added lessons possible after each evolution. Keeping the 
process simple increases participation. This can be accomplished if a Navigator can sit 
down at a readily available personal computer, quickly fill out pertinent comments, attach 
a picture if necessary from a digital camera to clarify the situation, and electronically 
submit a completed form. Building a robust repository where contributors can quickly 
see the fruits of their effort and benefit from other users is the key to a successful system. 
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3. 



Port Data 



There are several areas of interest in addition to navigation for ships preparing to 
enter port. Much of the time sensitive and ship dependent information is supplied 
through message traffic in reply to the logistics request (LOGREQ) message sent before 
entering port. Searching the WWW for information on world ports yields considerable 
information in a variety of formats. The intention behind this portion of GatorNet was to 
show the functionality that could be achieved through simple, static web pages. Area 
commanders could use these web pages to disseminate pertinent information and provide 
guidance to ships preparing to enter port. The potential use is unlimited and could range 
from pertinent instructions or regulations, a calendar of events, schedules for opareas, 
weather forecasts, or points of contact. 

B. PROTOTYPE FUNCTIONALITY 

The prototype is designed to be as user-friendly and as self-explanatory as 
possible. On-screen examples are provided for clarity, and help buttons are available if 
necessary. Image icons, point and click maps, and drop down lists were used extensively 
to provide the inexperienced web user a simple interface. 

1. “GatorNet” Homepage 

The GatorNet homepage is displayed in Figure 4-1. It provides links to the major 
areas of the prototype mentioned previously. It also provides the user with a statement on 
the purpose behind the prototype and who to contact if there are questions. 

2. Ports 

Selecting the Ports Icon presents the user with a world map for the user to view 
and select a port. After selecting the Southwestern United States, the user can gain access 
to the prototype site of San Diego. Figure 4-2 contains the San Diego harbor navigation 
frame presented to the user. The Ports section of the prototype is one of the primary 
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methods of accessing pictures of navigation aids. For the prototype, sections of charts 
18765 and 18773 were scanned to assist the user in correlating pictures with aids. 



GatorNet 

The Navigator's Planning Network 





Ports | Lessons Learned Database | Survey Results | Thesis | Navigation Hot Links 

About GatorNet.... 

GatorNet is a prototype site to enhance feedback and improve planning for Navigators of all flavors. There are a 
finite number of ports on earth, and navigators have traversed their waters for many years. Modem navigation 
tools like GFS assist in open water navigation, but only serve a backup role for large ships during restricted 
channel and harbor transits. Differential GPS improves on GPS* accuracy but is still not widely available. Visual 
navigation is (and will be for quite some time) the primary tool for safely passing through restricted waters. 



Figure 4-1. “GatorNet” Homepage 

San Diego is a lengthy harbor transit, and to maintain enough detail yet minimize 
download time it was necessary to create several web pages containing portions of the 
transit. By selecting an outlined portion of the channel, the user is presented with Figure 
4-3. Aids that have pictures associated with them are highlighted and contain a link to an 
additional web page as depicted in Figure 4-4. If necessary, the pictures can be annotated 
before posting to clarify the actual navigation aid, describe where the picture was taken 
from, or present photographer comments. A user with an actual harbor chart can easily 
correlate the digital image to the actual chart. As photos are submitted, it is a fairly 
straightforward task for the administrator to highlight the chart and create new links. 
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Figure 4-2. San Diego Home Page 

The remainder of the icons on the Ports web page can be structured to contain 
pertinent information. Home Port could contain information from the area commander, 
links to local command web sites, or training information. Publications might contain 
downloadable Portable Document Format (PDF) documents such as Fleet Guides, 
portions of navigation publications (Sailing Directions or Coast Pilots) pertinent to that 
port, or other relevant instructions or regulations. For the San Diego prototype, Weather 
contains HTTP links to local area forecasts and tide information. The final product could 
contain a tide and current program, links to weather forecasts, sea-state observations or 
sunrise/sunset computations. 
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San Diego 
California 



Harbor Navigation 



Home Port 



Return to Homepage 



Publications 



Weather 



Operations 



Commercial Info 






Figure 4-3. San Diego Entrance 



Safety could contain Local Notices to Mariners, pertinent Hydropacs or 
Hydrolants, phone numbers for oil spill response teams, or local mishap procedures and 
phone numbers. Commercial Information may show local street maps, phone numbers 
for tug or pilot services, provide entertainment or restaurant recommendations, or 
instructions on water and waste services. Operations is an area that could list schedules 
for exercises, communications, or training information. The ultimate design is only 
limited by the imagination. 
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Figure 4-4. Ballast Point Navigation Aid 

3. Lessons Learned 

As the user clicks the lessons learned icon on the GatorNet home page, Figure 4-5 
is displayed. Although named a “lessons learned database”, it is a relational database 
containing users, navigation aids, photographs, comments and voyage lessons. The rapid 
prototype contains five applications (CGI scripts) for querying Units, Lessons Learned, 
Photographs, Photograph Comments, and Navaids. It also contains three applications for 
Voyage Entry, Photo Submission, and Photo Comments. The user accesses these query 
forms by pressing the appropriate button. 
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Navigation Lessons Learned Database 



The prototype database contains information concerning ships, voyages (harbor transits, straits transits, 
etc.), navaids, and photographs. The database is a "slimmed down" version of the extensive relational 
database that would be required to truly contain the enormous amounts of data for navigation planning 
(hit "Schematic" link below to see how database is accessed). To demonstrate the functionality of 
accessing or entering navigation data and the types of queries that can be performed, choose a link below. 



Lessons Learned Search 



Unit Search 






mm 



NavakI Search 




ii, *m.unmn,i 



Submit Photograph 



Vi' 



Database Schematic 



Lessons Learned Search | Photo Search | Navaid Search | Unit Search 
Submit Lesson | Submit Photo | Comments | Help | View Database Schematic 




*■£>- 



’ Return to Homepage 



Figure 4-5. Lessons Learned Main Page 



Since the only photographs currently populating the prototype database contain 
navigation aids, both the Navaid and Photograph Search buttons display Figure 4-6. 



kctor/vJe,, Navaid Query 




NavAid Name: 
Chart Number: 



Type of Navaid: 

Find Reset Values 



Hfe' *' " 



Figure 4-6. Navaid Search 
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In the final product, pictures of tugs, piers, fittings, or even equipment like brows 
or cranes could populate the database. Figure 4-7 illustrates the query form for a 
“Lessons Learned Search”. All query forms have a similar look and feel. If left blank, all 
records will be displayed. To narrow the search standard operators (>,=,<, contains, 
begins with, etc.) can be used for matching. Once the “Find” button is selected, matching 
records are returned as in Figure 4-8. The user can “drill down” to gain amplifying 
information as in Figure 4-9 by selecting the hyperlink field. 

To minimize response time, the picture is a selectable button. A user can provide 
comments on the picture if deemed necessary as in Figure 4-10. This allows a 
mechanism for feedback and allows future users to gain more confidence that the picture 
they are viewing is in fact the proper navigation aid. A radio button scale from one 
through five is provided when submitting pictures or when commenting on pictures. 
Since am inaccurate picture could be a potential safety hazard (misinformation could be 
more detrimental than no information at all), this confidence ranking system and the 
ability to provide additional comments are two methods to mitigate potential problems. 



faQ-torNe, 


Voyage Query 

,5 


Event Date: 


1= d 1 


Country: 


1 


Chart Number: 


i 


Hull Number: 


1 


Ship Class: 


] Begins With H | Jjj 


Voyage Name: 


| Contains | Port Visit 


Find | Reset Values j Leave All fields blank to see all lessons. 





Figure 4-7. Lessons Learned Search 
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When submitting either a lesson (voyage, harbor transit, anchorage, exercise, etc.), 
photograph or comment into the database, the records are added to a temporary database 
where the administrator can sanitize the information. Although an extra step for the 
administrator to validate and transfer records to the master database, this provides a 
measure of security against user mistakes, intentional misinformation or spoofing, or poor 
entries. An Access ‘97 macro could easily be written to transfer validated records and 
append the master database. All queries access the master database that contains the 
sanitized information. 

Figure 4-11 contains an example of the Photo Submission Form. The same user 
information is collected when entering a photograph, lesson or comment. By collecting the 
phone number, point of contact, and e-mail address, a future user should be able to 
quickly contact the originator should there be questions. With the proliferation of e-mail, 
the day when service members can easily be located even after transferring to new 
commands is at hand. This added feedback mechanism is invaluable, and would have 
widespread application beyond navigation. 

Pictures can be related to specific voyages or can be entered independently. When 
entering voyage information, a voyage identification number (the database table primary 
key) is provided to the user for reference when submitting photographs (9999 is used as 
the default if the photograph is submitted independently). After submitting a photograph, 
a photo identification number is provided for annotating on the back of a mailed 
photograph or attaching to an electronically submitted photograph. These measures 
provide the database administrator with a mechanism to keep voyages, photographs and 
data records correlated. 



52 



^ a torM e/ Matching Navaids 



There are 9 matching records. Displaying matches 1 through 9. 



Chart Number 


NavAidName Type of Navaid 


118773 


PT Loma Lighthouse Lighthouse 


118773 


Ballast Pt. Light 'Light 


18773 


Old Lighthouse Lighthouse 


18773 

* i 


“Z“ Light Light 


1 8773 Entrance Range Front Light 


'18773 


Shelter Island “S“ : Light 


18773 North Island "4" Light 


18773 


N.Island "N" Light Light 


18773 


N. Island Aerobeacon Light 



Figure 4-8. Matching Record Form for Navaid Search 



Figure 4-12 shows the initial portion of the details from a sample voyage entry. 
Other pertinent navigation information such as visual navigation, radar navigation, tug, 
tides/currents, depth and many other areas are collected on the voyage entry form. If a 
field is left blank during record submission, the field is not displayed when querying. 
Memo field data types are used to store comment information and minimize the size of 
the database. Only the amount of information typed in by the user is stored and not a 
fixed record size. 
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Navaid Details 


NavAid Name: 


Entrance Range Front 


Type ofNavaid: 


Light 


Chart Number: 


18773 


Lat/Long: 


3242.3N11714.0W 


PubDeseription: 


L. List: No. 1500; Front Range Q G. 22 ft, KRW on white column; 




KRW on skeleton tower, visible 4 deg each side of rangelme 


Click for picture 




Comment on Picture | 


View Al Comments) 





ugure 4-9. Matching Record Detail 



PO 



*C:« 



Photo Comments 



Hull Number 
Ship Class: 

E-Mail Address: 
Phone: 

Unit Point Of Contact: 



LPH-11 (IELPH-11) 
[lp 3 

gator(«>newof leans. navy, mil 
DSN 656*1 01 5 
Karl Thomas 



ExtraComments: 



Once established on the 356 leg, 
channel buoys can be used to help 
locate the range Range is typically 
visible to the nakefc eye before the 



d 



Confidence: Low ( ~l f ~2 f ~3f'4( ? 5 High 
Save | Reset Values | 



Figure 4-10. Photo Comments Submission Form 
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katorNe,, 

jiLd 


Photo Submission 


Hull Number: 




(IELPH-ll) 


Ship Class: 


|ad 


”3 


E-Mail Address: 
Phone: 






Unit Point Of Contact: 


r 




Chart Number. 

Voyage Number. |9999 


(Change only if assigned a new number when enterring Voyage feedback form) 


Lat/Long: 




(IE 3252. 3N1 1714.2'W) 


NavAidName | 
Type ofNavaid: | Light 


d 


Date Picture Taken: 


|WMMDD (Must enter numbers or will receive an error!) 


Photographer's Comments: 


3 


Confidence Level: Low 




d 

r l C2C3CA r 5High 


(How confident are you die picture is the Navaid specified?) 



Figure 4-11. Photo Submission Form 



0 GtorN e/ 


Voyage Details 




6 


Event Date: 


970508 


Chart Number 


21338 


Hull Number: 


PC-8 


Voyage Name: 


Puerto VaUarta Port Visit 


Country: 


Mexico 


Lat/Long: 


2039N10515W 


Pilot Ranking: 


9 


Pilot 

Comments: 


PILOT IS COMPULSORY. PILOT IS REACHED VIA BB CH 16 “CAPITANIA, PUERTO 
V ALLART A" TRANSLATES TO ‘HARBOR MASTER, PUERTO VALLARTA.* PILOTS SPEAK 
ENGLISH PILOT BOARDED 1 MILE SOUTH OF BREAKWATER. 



Figure 4-12. Lesson Learned Search Result 
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4. Survey and Thesis Results 

In order to disseminate the large volume of information collected in the fleet 
survey, the results are posted on the GatorNet prototype. Links are provided to the 
graphical and tabular results of Chapter II and the Appendices. The narrative comments 
listed in Appendix E are also provided. Users viewing the survey information are free to 
make comments, adding to the feedback available to future GatorNet developers. The 
“thesis results” section of the prototype contains an HTML version of this document 
accessible by chapter. 

5. Navigation Links 

While conducting research and developing the GatorNet prototype, several useful 
web sites were discovered. These sites are organized on the Nav Links page. This could 
be an expanding and evolving page containing links to ports, users, navigation products, 
navigation research and development projects, or anything else pertinent to navigation. 

C. SEMANTIC OBJECT MODEL 

When designing the database structure to contain the repository of information for 
the prototype, the semantic object model was chosen over the entity relationship model. 
Semantic Object modeling is particularly well suited for the bottom-up development 
approach taken toward the rapid prototype [Ref. 27:p.47j. This choice was also made due 
to the availability of and familiarity with the SALSA schema generation software. 

The initial database structure was a vast, all encompassing effort to design a 
database that could accommodate a full-scale GatorNet implementation. Approximately 
15 objects were used and included navaids, charts, ports, piers, pilots, hazards, individual 
users, and units to name a few. Several of these objects had group attributes and 
attributes with maximum cardinalities of “N”. Once the schema was generated, well over 
30 tables existed. Schema generation was not difficult, but as applications were 
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developed to access the relational tables it quickly became apparent that a greatly scaled 
down version would be needed to manage the scope of these applications and complete 



the rapid prototype. 

When using relational tables, foreign key management becomes critical. As the 
number of objects and relations increase, the application development becomes 
increasingly difficult. The other extreme is to use a flat file scheme, but this results in 
considerable data redundancy. Figure 4-13 contains the five objects used within the 
prototype and their associated data attributes. These objects provided ample information 



to prove the GatorNet concept. 




Chart 

LatLong 

NavakDD 

NavAidName 

PhotoAvg 

PubDescription 

Type 

ImageFileName 



Voyage£D 

AnchorageComments 
ApproachCornments 
ChannelComments 
Chart 
Country 

DepthComments 
EventDate 
HazardComments 
LatLong 

OtherComments 
Pier Corn merits 
Pilot Ranking 
PilotComments 
Visual Nav Ranking 
VisualNavCommerits 
Radar Nav Ranking 
RadarNavComments 
Tide&CurrentsComments 
TrafficComments 
Tug Ranking 
TugComments 
UnitJiullNo_FK3 
VoyageName 

m 

Figure 4-13. Database Objects and Relations 



NavAid Navari© FK2 



I Voyage VoyageJDBCl 



Photo© 

PictureDate 

Image HyperSnk 

NavAid_NavaidID_FK4 

Comments 

ImageTransfer 

Confidence 

Unit© FK 





v ip fw • ■ *1 

1 / 

IT#,/* M W 


SSSS9B9] 


lUhUD 




CannertJD 


|l Class 


siPSRSl 


ExtraComments ! 


j E-Mail 


m&m 


Date 


JHuflNo 


1 I |9p 


Confidence 


iPhone 


Photo_ID_FK 


(1 PointOf Contact 




UnitJD^FK 







D. RELATIONAL DATABASE 



Access ’97 was used for the relational database software for several reasons. The 
primary reason was familiarity and availability of the software package. Additionally, 
since Microsoft Office ’97 has been mandated as the standard for IT-21 [Ref. 13], it made 
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sense to use a software package that will be widely available throughout the fleet. 
Furthermore, since Front Page was the web development software and Microsoft Internet 
Information Server (IIS) the web server, using solely Microsoft products decreased 
chances for incompatibility. 

To minimize complexity, auto-generated primary key integers were used for each 
object. Prior to each new record entry, a direct DBMS action is performed by the Tango 
middleware (discussed later in the chapter) to determine the last record in a table. The ID 
is incremented by one and a new record created. 

1. Unit Table 

In the prototype, every time a user enters information for a new photograph, 
comment or voyage a record is added to the Unit table. This creates obvious data 
redundancy. In the final product, a password and user-ID scheme would end this 
drawback and keep the administrator from having to purge the Unit table of duplicate 
records while correcting the unit foreign keys within other tables. 

Both Hull Number and Ship Class attributes exist to allow searches on either item. 
A more robust system would accommodate staffs and individual users. A unit can be 
related to multiple photographs, comments, or voyages. Therefore, the foreign key of the 
unit resides in those tables. 

2. Photograph Table 

The photograph table is straightforward. The Confidence attribute stores a 1-5 
value assigned by the photographer rating how sure that particular picture shows the 
actual navaid. This allows a degree of reliance to be placed in pictures by navigators 
using the system. The Image Hyperlink contains a hyperlink to the JPEG filename. The 
Image Transfer attribute is not functional, but was designed to store a binary value 
depending if the image was electronically submitted or mailed to the database 

administrator. The foreign key for Navaid is in the Photograph table since a navaid 

conceivable could have more than one picture submitted. 
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3. Voyage Table 

The attributes contained in the Voyage table allow a basic lesson learned format 
geared toward a restricted water transit. The multiple Comments attributes use the memo 
field and allow text based discussion. The Ranking attributes contain an integer between 
1-5 as selected by the user with a radio button. This ranking mechanism could be used to 
collect opinions over time and develop statistical data on tugs, pilots, visual and radar 
navigation aids. This would provide yet one more feedback mechanism for a navigator 
during preparation. 

4. Navaid Table 

The Type attribute is a drop down list to categorize navigation aids (light, 
lighthouse, buoy, structure, building etc.) and assist in queries. The Image File Name 
attribute stores the JPEG filename. Pub Description includes information that is found in 
the various planning publications as a way of consolidating information into one easy 
access location. Photo Avg. stores the average value computed from the photographer’s 
and other user’s confidence entries. 

5. Comments Table 

This table captures comments made by users when viewing pictures already in the 
database. Units can make multiple comments, and photographs can have multiple 
comments made on them so both of these foreign keys reside in this table. The date is 
automatically entered when the user submits the comment. 

6. Navaid Voyage Table 

This table is required since voyages can contain multiple navaids, and a navaid 
can be associated with more than one voyage. Both foreign keys are contained within the 
table to relate the two objects. 
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E. 



TANGO FOR ACCESS 



In order to assist in developing applications to access the database through the 
GatorNet web site, we chose EveryWare Development Corporation’s Tango product. 
This product provides a straightforward method to create basic query documents for 
accessing a relational database and formatting returned results. When searching for 
information from more than one table, the software allows the user to define joins. 
Creating applications to enter new records into a single table within the database is 
accomplished by using the New Record Query Builder function in the software. 
Expanding the functionality to enter data into related tables is accomplished by creating 
query documents for each table, and combining them by cutting and pasting the HTML 
code. SQL statements were used to increment primary keys and ensure foreign keys were 
entered into appropriate tables. Very little altering of the Tango-generated forms was 
necessary to obtain the figures shown throughout this chapter. Although not entirely 
point and click. Tango for Access greatly reduced the CGI coding requirements to 
achieve database interaction. 

The Tango Server executes the requested query documents, performs the 
operations defined in the document, communicates with the database, and returns the 
results to the IIS server to be passed on to the user. A plug-in is provided for Microsoft’s 
IIS to speed up the passing of information between the two servers. An application was 
required for each of the functions outlined in the previous Lessons Learned section of this 
chapter. 

F. WEB INTERFACE DEVELOPMENT 

Front Page ’97 was chosen for developing the GatorNet site. The primary reasons 
behind choosing this software package was availability and the compatibility with 
Microsoft IIS, Access 97, and the Windows NT operating system. The structures for 
several web pages within the prototype were created using wizards available within the 
software. No significant problems were encountered during development or publishing. 
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G. 



PROTOTYPE HARDWARE/SOFTWARE REQUIREMENTS AND COSTS 



The prototype was developed on a 200MHZ Intel Pentium personal computer 
with 32Mb of RAM. Pictures were taken with a personal 35mm camera using an 80- 
210mm zoom lens. Images were scanned into the prototype using a HP ScanJet 4P 
scanner. No other special hardware was purchased or required. No special software or 
hardware was required so costs were truly kept to a minimum. 

The following software was used to develop the prototype: 

• Microsoft Office 97 (Word, Excel, Access) 

• Corel Photo-Paint 5.0 

• FrontPage 97 

• Tango for Access 

• Salsa Academic Edition for Students V 1 .1 

• Microsoft IIS 

• Microsoft Internet Explorer and Netscape Communicator 

• Windows NT 4.0 

All software except Tango for Access was either already owned by the authors or 
available on the NPS personal computer used to develop the prototype. Tango’s 
educational version cost under $150. As a benchmark for other rapid prototype 
developers, it is estimated that the suite of hardware and software used to develop and 
serve the prototype cost under $4,000. A full-scale implementation of the GatorNet 
concept would require much greater redundancy, speed, reliability and security and 
consequently be more expensive. 

The site is served from the same personal computer used to develop the prototype. 
The computer is connected to a 1 OMBPS-Ethemet network at the Naval Postgraduate 
School and is accessible at http://pcicm 1 .ece.nps.navv.mil/Gatorhome.htm . 
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V. 



FLEET IMPLEMENTATION OF A NEW NAVIGATION PLANNING 
SYSTEM AND ASSOCIATED INTEGRATION ISSUES 



A high visibility and priority item in fleet navigation today is the program to 
finally transition from paper to digital nautical charts (DNC). The Electronic Chart 
Display and Information System (ECDIS) would accomplish this and be based on 
commercial standards that have extensions for military applications. Navigation sensors 
(such as GPS/DGPS/Inertial Gyros) will provide inputs to the system to allow positional 
display and assist in route planning and route monitoring. This system will significantly 
enhance safety through automatic grounding avoidance and audible alarms should the 
ship approach danger areas. In a brief dated 6 October 1997, RADM Tobin (N096, 
Oceanographer of the Navy) addressed these issues in an attempt to develop a cohesive 
transition plan and develop official Navy policy. Full fleet implementation would not be 
completed until fiscal year 2005 [Ref. 28]. 

The route planning available in this system would be enroute planning and assist 
in course, speed and time calculations. It is not the restricted water planning that has 
been the major thrust behind the GatorNet prototype. Commercial-off-the-shelf programs 
are available that assist in both types of planning. For example, the Cap’n is widely used 
by the fleet (Chapter II) and is ideal for enroute planning where Fairplay’s CD-ROM 
contains a database of port information oriented toward commercial shipping information 
for the world’s ports. Although ships can use these packages, they are not officially 
sanctioned for safety and liability reasons, and can place Commanding Officers in 
difficult positions should they rely on them to the neglect of other official sources. 

By the year 2005, processor performance will have doubled fully five times if 
Moore’s law holds constant. Optical devices will likely make data storage a non-issue. 
Low orbit satellite constellations will provide worldwide high bandwidth connectivity. 
What type of navigation systems could be built with these capabilities? The prospect of 
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being stationed on the last ship to receive yesterday’s technology in the year 2005 is not 
very enticing. 

A. NAVIGATION PLANNING 2001— AN INFOTECH ODYSSEY 

10 October 2001. USS Carl Vinson (CVN-70) has just been upgraded with the 
Navy’s latest C^ISR systems as it conducts work-ups in preparation for extended 
deployment to the Mediterranean. The crew is excited about it ’s upcoming port call in 
the newly opened port of Havana, Cuba. A search of the Navigation-Archives CD-ROM 
has provided a good overview of port services, and photographs of the piers and tugs 
collected from overhead imagery and commercial ships. The tide/current module 
produces chartlets with graphs showing predicted tides and currents for the date of the 
planned transit. Unfortunately, the ship’s navigator, LT Tobin Jr., knows the 
Commanding Officer will have many questions at the Navigation brief. He anxiously sits 
down at his Pentium 11 300 and connects to the SIPRNET to query the “Ports 
Application” on GCCS. Because this is the first US ship to visit the port in over 40 
years, he expects to find very little within the extensive lessons learned database. To his 
surprise, a Canadian combatant recently visited the port and has included a QuickTime 
video taken from their mast-mounted camera during the transit. He requests the video 
and places a priority level of two on the video information packet. Priority two 
corresponds to transmission over the Global Broadcast Service within the next six hours. 
For the meantime, he downloads the compressed audio debrief given by the Canadian 
Navigator on difficulties encountered during the transit as well as a description of the 
tugs, pilot, and berthing facilities. Just as scheduled he receives the video. The 
videographer has done a great job highlighting key navigation aids and features. The 
combination of the video and the audio debrief answer many of LT Tobin’s questions. 
Knowing the system will have automatically queued and compressed pictures of the 
primary navigation aids, with another press of a button he downloads the pictures 
directly into the memory of the recently arrived electronic telescopic alidades. The new 
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devices have split viewfinders (one side digital image, other side zoom-telescope) and are 
networked to the digital chart table to provide an electronic line of position and 
instantaneous fix at the push of a button. These fixes are automatically compared with 
DGPS to provide input to the ship s autopilot during restricted water transits. 

Unfortunately, one of the navaid files is corrupt so LT Tobin seamlessly accesses 
the user database to contact the officer that submitted the file. After "whiteboard 
discussion ” on a digital chart overlay of the harbor, the Canadian promises to resubmit 
the automatically archived file — all navigation, exercise, and lessons learned 
submissions are archived onto a personal removable Jazz drive that is assigned to the 
user (the Canadian in this instance). As users transfer between commands, they bring 
their drive with them and leave a copy at the command’s electronic data repository. 
When individuals leave the service, the archives are maintained at the central repository 
for that particular service. Within a day the original file has been retransmitted, the 
previously requested burst download of satellite imagery for the port has been received, 
and the navigation team and Commanding Officer feel exceedingly well prepared to enter 
a port they ’ve only virtually seen. 

Everything described within this fictional scenario is technically possible today. 
The necessity for this capability might be a bit far-fetched to make a port call, but if the 
scenario is applied to a wartime amphibious operation or navigation of a minefield the 
argument against this capability is without substance. 

B. WHAT IS NEXT FOR GATORNET? 

The primary purpose behind a prototype is to ascertain user requirements. It 
should be created rapidly to speed up the system development life cycle (SDLC). Since 
there are no known initiatives currently in progress to develop a planning system like 
GatorNet, the goal has been to generate discussion and feedback for a well-defined 
requirements package. Additional goals of the prototype were to: 
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• Demonstrate new navigation-planning functionality that can be achieved with 
Information Technology and little programming effort (photographs, relational 
database, lessons learned) 

• Change the way navigation planning is conducted, via active submission of 
lessons/pictures versus passively reading publications. 

• Combine the numerous navigation sources into a “one-stop shop” of information. 

• Introduce the concept of an online navigation forum. 

The National Image and Mapping Agency is in the process of updating the 9600 
baud NavInfoNet to a dynamic web site. If one designer of the new system accesses 
GatorNet and is influenced by the possibilities or implements one of the concepts, the 
prototype will have served its purpose. 

C. INTEGRATION ISSUES FOR FLEET IMPLEMENTATION 

Fielding a new system with the capabilities displayed in the prototype raises many 
integration issues. These issues have been organized into architectural, operational, 
personnel, cultural and economic categories. 

1. Architecture Issues 

Chapter III discussed many of the advantages and disadvantages of methods to 
distribute GatorNet information. With much of the information fairly static (port data), 
historical (lessons learned), or in a self-contained program format (course/speed/distance/ 
tme planning or tide/current calculations) the requirement for an “on-line” system is 
mitigated. Designing the system to be internal (hard drive resident programs with CD- 
ROM repository), improves the speed of the system and frees up valuable bandwidth for 
other applications. However, there are several functions that would benefit from a real 
time system including safety-related issues, retrieval of up-to-the-minute changes, or the 
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ability to contact a user for immediate feedback. Developing a hybrid system captures 
both of these advantages. 

The architecture issues that follow are at the top of the integrated Fleet 
Commander in Chief s priority list [Ref. 24]. By the time a GatorNet system could be 
developed and introduced to the fleet, most of these issues will likely be solved. 

a) Connectivity — Which pipe? 

There are several initiatives to improve connectivity throughout the 
military. “C 4 I for the Warrior” is the Joint Staffs military information architecture 
designed to provide a fused, real time, true picture of the warrior’s battlespace [Ref. 9:pp. 
6-7]. As more systems are networked and increasingly more information becomes 
available, greater demand will be created. Convincing intelligence users, tactical 
watchstanders, and system administrators that the navigation planning evolution merits 
system time will be a difficult hurdle. If this can be accomplished, creating a GCCS 
application for navigation may be one alternative to meet this new demand. 

Global Broadcast Service will provide an exponential increase over 
current SATCOM capacity. Capitalizing on commercially developed digital broadcast 
service (Direct TV) technology, users will request information (navigation) via 
conventional communications (e-mail) and receive a broadcast (port images/data) through 
a low cost receiver and small antenna [Ref. 12]. This smart push/warrior pull concept 
provides a viable conduit for implementing the GatorNet concept. 

b) Bandwidth 

How much bandwidth would a system with GatorNet’ s functionality 
require? A 28.8 KBPS modem that results in 3 KBPS throughput of data (due to 
communication overhead) has provided sufficient capability for prototype access. 
Bandwidth at sea will continue to be a resource highly sought after, as more systems are 
adapted to the information age. Compression techniques will aid in reducing the 
requirements. Initiatives such as Automated Digital Network System (ADNS) will allow 
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better sharing of bandwidth and provide a four-fold increase in throughput efficiency 
[Ref. 24], Although a significant issue, it is already receiving considerable attention for 
much higher bandwidth applications such as video teleconferencing. 

Server side bandwidth is critical to ensure proper expected response to the 
fleet. Based on the possibility of 500 users simultaneously requiring 3 KBPS each, a 
minimum 100 BaseT, FDDI, or OC-3 connection should be supplied to the network 
access point (NAP). This currently is in conformance with IT-21 standards. 

c) Storage Requirements 

By analyzing the rapid prototype, a projection can be made for the data 
storage size requirements of a full-scale implementation. The entire prototype site was 
just over 3 Mb, but contained additional information such as survey results, the thesis, as 
well as scanned images of charts. A fleet implementation could incorporate portions of 
vector format charts like those used within GCCS applications. The San Diego harbor is 
rich in navigation aids and contains more than would normally be available in the 
“average” port. Estimating that the average port requires 25 pictures of navigation aids, 
pier facilities, and port views and that each picture is 20 Kb results in 500Kb. Adding 
two chart segments at 50 Kb each and ten text-based web pages of information at 4 Kb 
brings the total port requirement to 640 Kb. An extremely robust set of extensive lessons 
learned could bring the total port size to 700 Kb. Using compression techniques well 
over 100 ports could be contained on a single CD-ROM. This approximates the number 
of ports the Navy regularly visits. 

Theatres of operation could be created such that ships could download 
information prior to arrival. By packaging the data in compressed files, users could 
retrieve the information while pierside, or during “off-peak” times so as not to compete 
for limited assets. Flagships that have more bandwidth capability could download the 
files and distribute them to the remaining ships within the task group using Iomega ZIP 
or JAZZ disks. There are many alternatives to distributing and disseminating the 
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information. The important point to be gained from the prototype is that the file sizes can 
be minimized and standard 28.8 KBPS modems provide quick site interaction with 
minimal delays. 

d) Standardization 

The information required to provide a comprehensive navigation planning 
tool already exists. Digital Nautical Charts, navigation aid descriptions, lessons learned, 
and navigation publications reside in several independent repositories. The advantage of 
connecting these sources together into a coherent system (band-aid approach) would need 
to be weighed against creating a new relational or object oriented database that provides 
seamless integration of data. Whichever approach is taken, the system must be Defense 
Information Infrastructure Common Operating Environment (DII COE) compliant to 
allow wider dissemination [Ref. 13]. Using TCP/IP and the SIPRNET for the online 
portion of the system is one easy alternative. Considerable work addressing 
standardization has been accomplished with the Common Operational Modeling, 
Planning and Simulation Strategy (COMPASS) that establishes a set of standards for C 4 I 
system and modeling and simulation system interaction. [Ref. 8]. 

Developers of a follow on application to GatorNet must balance the need 
for adequate detail within graphics while minimizing file size to reduce transfer times. A 
standard would need to be set for compression factors to ensure a minimum resolution 
was maintained. To ensure users understand the compression factors and to prevent 
misinterpretation of photographs, each image could either be annotated or have a 
corresponding database field to display the compression value when the picture is 
displayed. Defining these and other data standards and functionality is the first step in any 
system development. 

e) Reliability and Accountability 

Any system that will provide navigation planning information must have 
complete reliability. This explains the prolonged use of hardcopy chart and publications 
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within the Navy. If a ship must go into harms way, not having access to the necessary 
tools or information is unacceptable. This requirement calls for the minimum planning 
tools to be incorporated in a self-contained system — one that is not reliant on external 
communication sources beyond the navigator’s control. Navigation information is 
currently updated through the mail on a weekly basis. If a ship is transiting OP AREAS in 
the Indian Ocean, quite often conventional mail can be delayed up to a month. Although 
a self-contained vessel, a naval ship cannot conduct its mission today in politically 
sensitive climates without access to Command and Control conduits. The line must be 
drawn somewhere between online reliability and internal systems. Designing a system 
to run on an IT-21 compliant personal computer that can quickly access a network for 
compressed program/safety updates should be the minimum approach. As a backup, the 
defense message system could always be used to send safety related information should 
the primary network be unavailable. 

f) Security 

The vast majority of navigation information is unclassified and widely 
available in open sources. Should the system be expanded to include exercise data or 
navigation contingency plans, greater security would be required. Commercial mariners 
could provide significant feedback to a navigation repository, but this adds the 
requirement of protecting the data from deliberate manipulation or denial of service 
attacks. Since the system has national security implications, keeping it within DoD is the 
best way of providing security. Using a protocol that supports encryption and a conduit 
that protects the information (SIPRNET) is the most feasible answer. 

2. Operational Issues 

Assuming a planning system is developed, how would information be gathered to 
increase the system’s utility? Many of the mechanisms are currently in place. NIMA and 
the US Coast Guard already gather and update the primary navigation planning 
publications. Ships are tasked to submit port visit reports to update the Port Directory. 
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Many fleet commanders require lessons learned messages to be included in passdown 
folders. Collecting all this information into one location requires a centralized point of 
contact. 

Adding shipboard procedures to collect meaningful photographs would only 
require prior planning. The manning is in place (Photographer’s mates could be tasked or 
any individual not involved in the sea detail) and the equipment is available. With the 
improvement in digital cameras, uploading photographs would be straightforward. If 
pictures can’t be taken during the transit, quartermasters could use the Captain’s gig or 
motor whaleboat to document the harbor once in port. 

Gathering data would also be simple if electronic debrief forms are available to 
capture information following each and every navigation evolution. These forms could 
be transmitted immediately if connectivity is available, or stored for later transmission or 
submission via postal service on disk. The biggest hurdle would be changing the mindset 
of the users. Once the advantages that can be gained are apparent, user support should 
follow. Training can be conducted within the fleet navigation schoolhouses, or could be 
accomplished through distance learning programs. 

3. Personnel Issues 

Maintaining an online site with vast quantities of data would require considerable 
support during the “build-up” phase. Once the majority of frequently visited port 
information was converted or documented, manning could be reduced to support 
incremental updates and requests. A small staff savvy in the selected system architecture 
and navigation issues should be able to manage the project at that point. A staff could be 
comprised of two senior quartermasters, a junior enlisted individual for graphics support, 
a system administrator and an arrangement for part-time maintenance. Owning a large 
portion of the data and having direct access to the infrastructure, NIMA seems the logical 
choice to manage such a system. 
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Naval decision-makers are fully onboard with Information Technology being used 
as a way to leverage our shrinking fighting forces. As world commitments persist and 
deployment turnaround schedules shrink, manning issues will surely plague the Navy. 
Much of the quartermaster’s time is spent maintaining charts and publications, or laying 
tracks and calculating/graphing tides and currents. Adopting a navigation planning 
system that can reduce the manning requirements is certainly advantageous. 

4 . Cultural Issues 

One of the most difficult issues surrounding this concept is that of culture. The 
Navy is steeped in traditions and one of the earliest is precise navigation on the high seas. 
The adversity to changing procedures and accepting Information Technology has 
diminished as captured by the fleet survey results. Many of the sailors and officers utilize 
computers and are familiar with their potential capability if applied to the navigation 
planning process. By the time a new planning system could be implemented, many 
remaining “resistors” will have retired 

5. Economic Issues 

In this day of declining budgets, hard decisions are being made over which 
systems will be funded, which ones will receive upgrades, and those that will be cut. 
Although a considerable up-front investment would be needed to design a new planning 
system, the savings that can be generated through reduced paper products, distribution 
costs, maintenance costs, and personnel should justify the expenditure over the years. The 
intangible cost associated with the negative publicity surrounding a ship’s grounding or 
collision is hard to quantify. If a more comprehensive and current planning system 
prevents a single ship from running aground the system will have paid for itself. 

Combining development efforts between the Coast Guard, National Ocean 
Service, and NIMA could reduce costs. Both will have an online presence through 
NAVCEN and NAVINFONET. Both the Coast Guard and NIMA have similar concerns 
over navigation safety. The key to keeping costs at a minimum is to take advantage of the 
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research and development for related systems building. As mentioned earlier, NIMA is 
in the process of revamping the NAVINFONET. GCCS has well defined standards for 
data format and transmission, and many applications are being added to the system. 

D. FRAMEWORK FOR MANAGING PLANNED CHANGE 

The primary deterrent against implementing planning concepts from GatorNet 
will likely come down to a choice in priorities. Ships have been navigating in and out of 
world ports, through narrow straits, and within swept channels of mine fields without 
having the coordinated suite of planning tools discussed in GatorNet for many years. 
GPS has significantly improved ship safety near shore, and DGPS is improving the 
accuracy to within meters. The systems can already be used as a viable backup to visual 
and radar procedures within restricted waters. With other navigation initiatives like DNC 
and ECDIS in the limelight, GatorNet could easily be deemed a low priority as programs 
compete for limited funds. Unfortunately, these arguments could be made for many years 
to come as new programs emerge. So how should the fleet users who are obviously ready 
and willing to change (Chapter II) influence navigation planners? 

1. Is the Navy Ready to Change? 

Until recently, an argument for changing navigation planning methods would 
have been difficult to support. The infrastructure for any sort of online system was not in 
place. Computers with CD-ROMS and certainly networks onboard ships were limited. 
But now that these issues are being resolved, the remaining obstacle is changing the way 
we present and distribute information that (for the most part) is already being collected. 

Fleet users are increasingly computer savvy. They are aware of the leverage that 
can be gained through Information Technology. They thrive on technology and do not 
fear it like many previous decision-makers. The culture is ripe for change, but is the 
Naval Organization ready for change? 
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The Harvard Business School article Leading Change presents a conceptual 
formula that incorporates the critical dimensions of change that must be taken into 
consideration: 

Amount of Change = (Dissatisfaction * Model * Process) > Cost of Change 
Dissatisfaction is the source of energy that motivates change within the organization [Ref. 
29]. Although many navigators may see the benefits of or prefer a new planning system, 
how many are actually dissatisfied with the current system? The fleet survey identified 
quartermasters that are frustrated with the need to correct publications and charts instead 
of having digital charts with computer updates. There are navigators that haven’t used 
the current lessons learned system or find it difficult to access. But these issues miss the 
central themes behind GatorNet. To raise dissatisfaction, users must first see what they 
are missing. The GatorNet prototype should raise awareness and hopefully increase 
dissatisfaction. 

There are many models used to evaluate an organization’s fundamental aspects — 
structure, processes, environment, people, strategies, tasks, and culture to name a few 
aspects. Once the relationships between these aspects are understood, it is easier to 
determine which lever should be pulled to initiate change. A future model of navigation 
planning is needed as a vision that would help galvanize the change effort. DoD is adept 
at creating visionary documents and programs for overarching efforts (such as JV2010, 
Copernicus, and C4I for the Warrior). The program managers in charge of navigation 
planning need to create a realistic visionary model that the organization can strive toward. 

A roadmap must be defined to aid in the change process. Users need to be 
brought into this process not only to obtain accurate requirements (fleet survey/evaluation 
of GatorNet), but also to buy into the change process. From the survey results, the 
majority of users appear to have “bought in”; now a change process needs to be defined. 

The equation states the product of dissatisfaction, model and process must be 
greater than the cost of change to achieve success. The costs associated with changing 
navigation planning are more than monetary. There is still a small cadre of “old-timers” 
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that believe in traditional navigation. NT1C lessons learned stakeholders may be 
threatened by a new system — the survey suggests the system has failed regarding 
navigation. Users of limited bandwidth would see another system competing for limited 
resources. The time required to develop and maintain this system would detract from 
others. The additional time required for users to assist in populating databases with 
quality lessons learned, photographs and voyage feedback would add to an existing 
workload. 

The amount of change likely to take place given this equation does not seem 
promising. However, one advantage of military decision-makers is the ability to order 
change and know it will be accepted. Given a properly designed system, once users 
experience the vast information stores that can easily be placed at their fingertips they 
will wish they had initiated change ten years earlier. 

2. When to Implement Change? 

The Harvard Business School Note: “The Challenge of Change” [Ref. 30] 
indicates the process of change “may be easier when the organization is in crisis: the 
situation is clear to all, survival is on the line; everyone recognizes that the way things 
have been done won’t work anymore.” There is no navigation-planning crisis present that 
will force the Navy to change. No crisis was needed to initiate the transitional change 
that has already begun. Navigation publications are now being distributed on CD- 
ROMS. A formalized lessons learned system now exists where one did not in 1991. All 
admirals and most commands now have e-mail addresses. Ships are being networked. 
IT-21 is providing the equipment necessary to implement a hard-drive resident database 
program, CD-ROM archive, or Windows NT client-server planning tool. Many 
initiatives are in place to increase connectivity at sea. With all these changes already 
taking place, it is time to redefine how we conduct navigation planning and harness these 
advances toward a coordinated navigation pieinning system. 
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VI. CONCLUSIONS 



A. SUMMARY OF FINDINGS 

1. Project Accomplishments 

Accomplishments of the thesis project are summarized as follows: 

a) Research Achievements 

• A review of existing navigation planning procedures was conducted and 
documented in Chapter I. 

• A study of existing fleet navigation information sources and initiatives was 
conducted and results were documented in Chapter I. 

• An analysis of how to improve the existing navigation planning process was 
conducted and results were documented in Chapters II and V. 

• A study of migration alternatives was conducted and documented in Chapter 
III. 



b) Rapid Prototype 

A conceptual Navigation Planning Information Architecture was proven via 
the GatorNet rapid prototype navigation-planning tool described in Chapter IV. The 
benefits of client-server information technology and potential benefits for the fleet have 
been shown. A relational database of navigation lessons learned and a graphical Web- 
based user interface were developed in the prototype to permit interaction with the 
database. The prototype “GatorNet” is on-line and is available for viewing (as of the 
publishing of this thesis) at: http://pcicml.ece.nps.naw.mil/Gatorhome.htm . 

c) User Requirements Document 

A fleet survey was developed and distributed to generate feedback, which 
has been consolidated into a requirements document. These requirements were 
documented in Chapter II and Appendix E. 
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2 . 



Lessons Learned 



a) Positive Lesson Learned 

A positive lesson from the project was that a full year was allowed to 
conduct the research necessary to develop the prototype. This year was actually needed in 
order to involve the navigation “users” in the process as mentioned in Chapter V (section 
D. 1). This capture of positive lessons is in keeping with the Chapter IV (section A.2) 
recommendation to capture positive lessons along with negative lessons from the fleet. 

b) Netscape Enterprise Server Installation 

An unsuccessful attempt was made to use non-Microsoft server software: 
Netscape Enterprise Server. This may have been due to the proprietary nature of 
commercial software design and the fact that all other software in the prototype suite was 
either a Microsoft product or a Microsoft compatible product. Once a Microsoft server 
product was used (Internet Information Server) there were no more compatibility 
problems encountered. 

c) Prototype Development Timeline 

The original project milestone date to complete prototype development 
was not met. Three more months were needed to complete and publish the prototype, 
because ample time was not allowed to learn the new software. If the original date had 
been achieved, more effort could have been expended to continue to keep the users 
involved, so that additional feedback could be incorporated into future prototype 
revisions. 
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B. 



PROJECT CONCLUSIONS 



1. Smart Ship Navigation Initiatives: A Good First Step 

The SMART SHIP project described in Chapter I was initiated by the Naval 
Research Advisory Committee and the Chief of Naval Operations, and the operational 
platform chosen was the USS YORKTOWN (CG-48). The project has been considered 
by many to be a major success, mainly because commercial-off-the-shelf (COTS) 
technology was added to the existing ship’s systems to achieve new efficiencies and help 
to reduce manning by 17% [Ref. 31], According to a senior Navy official, “YORKTOWN 
was able to cut billets off the ship by introducing technology and by letting the crew come 
up with better ways of doing things.” [Ref. 32] The same official stated that the 
efficiencies developed in YORKTOWN were gained by implementing “out-of-the-box 
ideas” generated on that ship. The ship found its new navigation efficiencies by using 
Digital Nautical Charting, the NAVSSI. system, Sperry’s Voyage Management System, 
and by reducing their chart inventory of two sets of up-to-date paper charts to one set. By 
eliminating their holdings of redundant copies of paper charts, they reduced the weekly 
chart maintenance hours by 50% [Ref. 33], 

2. Fleet Navigators are Ready for Automated Navigation Planning 

The authors were extremely encouraged to learn that the U. S. Navy navigation 
“users” support for automating manual navigation planning tasks is nearly unanimous 
(Appendix E). The findings from the survey show that it is widely recognized that 
opportunities exist to gain efficiency by automating manual navigation planning tasks, such 
as data collection and processing. However, maintaining one complete set of paper charts 
onboard ship, as is the practice aboard YORKTOWN, may be prudent for use as a “Battle 
Backup” method of navigating without reliance on communication satellites or computers, 
which may become casualties in combat. 
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3. The Coast Guard is Ahead of the Navy in Digitizing Navigation 

Significant navigation advances have taken place onboard U. S. Coast Guard 

vessels, as evidenced by the USCGC JUNIPER’S use of new navigation technology. 

Having been commissioned in early 1996, JUNIPER was called on to coordinate early 

efforts to recover aircraft wreckage from the TWA Flight 800 disaster. JUNIPER’S early 

ocean floor wreckage survey was conducted using DGPS and new voyage management 

software to successfully map ocean floor wreckage and to autopilot the ship to maintain a 

continuous position on top of wreckage. To summarize this process: 

The Juniper uses a GPS receiver as part of a shipboard fiber-optic local- 
area network (LAN). The LAN runs two key PC-based software 
packages: the Electronic Charting System, a computerized nautical chart 
developed by Offshore Systems Ltd.; and the Dynamic Routing System, a 
navigation software package created by Nautronix. By combining these 
programs with the positioning information, the ship has the capability to 
drive itself. The computer system enabled the JUNIPER to hold in place 
automatically by monitoring the GPS information and engaging thrusters or 
propellers... the crew could run on autopilot with precision by laying out a 
course on the electronic chart and then feeding it into the Dynamic Routing 
System. The JUNIPER tapped into the Differential GPS System (DGPS) 
which fine-tuned... the position to an accuracy of two meters [Ref. 34], 



This superior new technology has not yet been installed aboard Navy ships, but the 
new systems (NAVSSI and VMS) and initiatives proven in YORKTOWN are a much- 
needed step in the right direction. JUNIPER’S technology demonstrates the feasibility of 
allowing computer systems to autopilot ships into port. It is conceivable that in the future, 
ship visual navigation teams may serve only a supervisory role. 

A primary mission of the U. S. Coast Guard is to promote the safety of marine 
navigation. The Coast Guard does a thorough job of centrally managing navigation issues 
such as notices to mariners through the centrally managed NAVCEN WWW site. 
NIMA’s Marine Navigation WWW or SIPRNET page could be improved along these 
lines, by changing the current static design to an active one, which would allow 
continuous updates to navigation data. 
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4. The Network Centric Warfare Concept Should Include Navigation 
Planning 

The United States Navy’s leadership has embarked on an ambitious plan to 

leverage computer network technology in such a way that all administrative and even 

tactical functions are driven to the desktop computer; the IT-21 vision. Network Centric 

Warfare is a related concept of VADM Cebrowski, the Deputy Chief of Naval Operations 

for communications and computer matters. VADM Cebrowski’ s concept, 

Holds enormous potential for the surface navy. If you consider an Internet 
web page analogy, Network Centric Warfare will establish a wide area 
network of reliable satellite connectivity. In the past... it was only within 
the (ship’s) lifelines that you were able to pull together disparate data and 
make sense out of it in a given situation. Now the data for a particular 
mission is available to be pulled down... from the Internet. This will allow 
us to... maximize the combat capabilities of all our surface platforms. 
Network Centric Warfare will accelerate the information processing 
function and then distribute it to the total force. Ships in large numbers 
will then have the connectivity and tools available to... conduct mission 
planning, without having to rely on the large decks (such as aircraft 
carriers) [Ref. 35], 



In addition to the Network Centric Warfare concept, a “System of Systems” 
approach to manage heterogeneous navigation data and applications is also needed [Ref. 
36], The GCCS system is a perfect example of such a combination of systems. Numerous 
joint navigation applications and data sources could therefore be combined into a single 
powerful tool, thereby allowing true “one stop shopping” when it is time to plan a 
navigation evolution. 

5. There is a Definite Trend Within the Navy to Move Toward Digital 
Navigation 

The new attack submarine (NSSN) is being built with no chart stowage onboard. 
[Ref. 28] This is a significant indication that the U. S. Navy is committed to doing away 
with paper charts and eventually migrating to a fully digital method of navigation: 

The technological revolution has additionally impacted naval operations 

with respect to GGI&S (Global Geospatial Information and Services). The 
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Navy, in concert with NIMA (National Imagery and Mapping Agency), 
and national and international organizations, is moving to utilize a vector 
database keyed to positional information from GPS, to provide electronic 
navigational charting. The present goal is to utilize the Digital Nautical 
Chart (DNC) (TM) with worldwide production by 1999. ...In a parallel 
development, the New Attack Submarine (NSSN) is being designed 
without chart lockers and will fully employ digital charts and electronic 
navigation. Fully integrated navigation systems are clearly a long-term 
goal, but in the short term, we are encouraging the use of stand-alone 
electronic charting systems that are ready now to dramatically improve 
situational awareness for our bridge watch teams [Ref. 37]. 

In addition to the significance of a new vessel without paper charts, there is another 
important acknowledgement in the previous quote: that a fully integrated navigation 
system is needed. Navigation planning functions must be included in any new integrated 
system. 



6. Navigation Tradition and Culture Paradigms Need to Shift 

An uncomfortable tradition exists in the Navy regarding a ship grounding: A 

ship’s Captain and Navigator are guilty until proven innocent. Any such incident almost 

always results in the end of the careers of any officers involved with such a misfortune. 

This fearful tradition will make any changes to the paper method of navigation a tough 

paradigm to crack. Fortunately, Navy attitudes toward the culture of computer network 

technology are shifting, thanks to initiatives like IT-21 and others: 

As the information age in the Navy is poised to enter the (next) phase of 
development, we must go beyond simply improving our tools, and instead 
leverage those tools to fundamentally change our processes. This is the 
philosophy behind IT-21. It is a paradigm shift in how we create, manage, 
and retrieve information [Ref. 38], 



In 1997, YORKTOWN navigated to a precision anchorage in the Chesapeake Bay 
using the autopilot feature of the Sperry Marine Voyage Management System. When 
shifting to computer ship control, the ship’s officers give the command to the bridge 
console operator: “Shift control (of the ship) to the VMS!” The Naval Research and 
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Advisory Committee (NRAC) panel reported that the major obstacles to (SMART SHIP) 
reduced manning and decreased life cycle costs aboard Navy ships were culture and 
tradition rather than the lack of proven technology and know-how. Further, that 
expenditures on available technology and implementation of policy and procedure changes 
make manpower reductions achievable [Ref. 31]. 

C. RECOMMENDATIONS 

1. Continue Refinement of GatorNet Prototype 

The GatorNet prototype does not yet contain enough hard data for fleet 
implementation. Continued refinement of the system and widespread exposure to the fleet 
will help to further refine user requirements. With a larger database repository (e.g. all 
West coast ports photographed and substantially more lessons learned), GatorNet may 
eventually be added to a SMART SHIP or SMART GATOR platform as an experimental 
system in the very near future. 

2. Migrate GatorNet to the SIPRNET 

Use the SIPRNET as the C4ISR conduit and complete development of the 
GatorNet prototype into a beefed-up GCCS “Ports” application. Although the majority of 
navigation information is unclassified, any data or planning system is extremely vulnerable 
to Information Warfare. Because the security of this information is of vital importance to 
ship safety, it should be afforded a high level of protection such as that provided by the 
SIPRNET and GCCS. 

This migration should be managed to coincide with the NIMA initiative to digitize 
all navigation products for placement on the SIPRNET by the end of 1998. 

3. Transition the NTIC NLLS to the SIPRNET Through an On-Line, 
Interactive Client-Server Database Back-end 

As shown in Chapter II (Table 2-8), very few fleet users are using the current 
lessons learned system. An on-line system would save the considerable distribution costs 
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associated with the current method of quarterly CD ROM updates. Transitioning the 
NTIC NLLS to a secure system such as the SIPRNET would avail fleet users and other 
interested joint military planners of the latest lessons learned. Due to the ease of access of 
an on-line system, more lessons can be captured, including positive lessons along with the 
negative ones. In addition, capturing quantitative lesson data (along with qualitative 
information) would allow statistical analysis (e.g. rating averages) and a revised lesson 
questionnaire format could help to facilitate this. 

4. Designate a Single Agency to Manage all Migration Issues Associated 
with Automating Navigation 

During research for the thesis, it became obvious to the authors that there are 
several U. S. Government initiatives underway to improve maritime navigation. Some of 
these initiatives were described in Chapter I. This thesis has addressed an area believed to 
be wholly overlooked, which is the issue of migrating manual navigation planning tasks to 
automated methods. There exists a glaring need for our government and military to 
designate a single responsible office to coordinate and harmonize the numerous 
fragmented efforts currently underway. An annual national professional navigation 
conference or symposium would also greatly benefit all interested parties, such as the 
United States Navy, the United States Coast Guard, the National Imagery and Mapping 
Agency, the National Ocean Service, and the Maritime Administration. 

D. SUGGESTED AREAS FOR FURTHER STUDY 

1. Conduct a Study of All of the Latest Navigation Voyage Management 
Software 

The Full Utility Navigation Demonstration (FUND) software initial version was 
just released in December, 1997 [Ref. 20], The Defense Mapping Agency Mapping, 
Charting, and Geodesy Utility Software Environment (DMAMUSE) program is another 
ECDIS software title which should be reviewed in order to explore the feasibility of 
navigation planning product compatibility. Can these software packages, which were 
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primarily designed to manage electronic charts, also be leveraged to accept the full range 
of heterogeneous digital navigation planning products? 

2. Conduct a Review of all Relevant Databases that Contain Navigation 
Information 

A review of navigation data sources should be conducted. This will most likely 
require extensive travel and an appropriate security clearance, as some data is resident in 
classified databases. The National Imagery and Mapping Agency headquarters in 
Northern Virginia is a good place to start this study. In addition to surveying what 
databases (both commercial and military) are relevant to navigation planning, methods of 
integrating and consolidating the disparate data should be explored. 

3. Investigate the Feasibility of Marrying Littoral Digital Overhead 
Imagery with Navigation-Planning 

There exists in the fleet a tremendous need for easy access to near-shore and beach 
overhead imagery to help support key decision-makers in the planning for amphibious and 
special operations. An appropriate tool needs to be developed to properly identify and 
label such imagery, which has navigational value. For example, littoral imagery might 
show the presence of heavy offshore kelp, which could foul the screws (propellers) of 
certain displacement landing craft and cause decision-makers to opt to use air cushion 
landing craft. Similarly, littoral imagery might also show the presence of beach obstacles 
(either natural or man-made) or an unknown offshore sandbar that might make a particular 
amphibious or expeditionary operation infeasible or unacceptably risky. In many cases, 
existing imagery could be used rather than brand-new products. If necessary, national 
assets could be tasked in a crisis to develop this navigation-specific imagery, which could 
be pushed to planners through robust intelligence networks already in place in the fleet. A 
method needs to be developed to screen all near-shore imagery and label or tag those 
images which have navigational value, so that they can be “pulled” by warfighters to aid in 
time-sensitive operational decisions. 
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APPENDIX A. LIST OF NAVIGATION PLANNING PUBLICATIONS AND 

PRODUCTS 

This listing shows the majority of the hard-copy publications, charts, messages, 
and other products which are used in the manual navigation planning process. 

• COMNAVSURFLANT/COMNAVSURFPAC/AIRPAC/AIRLANTINST 
3530.4: Surface Ship Navigation Department Organization and Regulations 
Manual 

• Pub. 9, American Practical Navigator 

• Nautical Charts 

• N1MA Fleet Guides 

• Port Directory 

• Pub. 1 50, World Port Index 

• Pub. 151, Distance Between Ports 

• Pub. 152, Sailing Directions (Planning Guides) 

• Pub. 153, Sailing Directions (Enroute) 

• Notice to Mariners (NIMA/NOS/U.S. Coast Guard) 

• Local Notice to Mariners (U.S. Coast Guard) 

• Light List (U.S. Coast Guard) 

• List of Lights (NIMA) 

• Navigation Rules (COMDTINST M16672.2C) 

• U.S. Coast Pilots 

• Tide and Current Tables 

• Pub. 606, Guide to Marine Observation and Reporting 

• Summary of Chart and Publication Corrections 

• HYDROPAC/LANT Safety Messages 

• Nautical Almanac 

• Typhoon/Hurricane Havens Handbook 
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APPENDIX B. FLEET NAVIGATION SURVEY 



Note: Although you may not currently have access to the World Wide Web, please assume you have it or will have it 
in the near future when responding to these questions. Please feel free to use additional sheets for your responses, if 
necessary. Also, please indicate <f N/A” for questions which do not apply to your situation. 

1 . Please provide the following information: 

Rank Title Time in billet (mos) # QMs on board 

Command (Staff or ship platform (i.e. DESRON, CV, etc.) 

Current command status (ashore, deployed, maint. availability, etc.) 

2. The new National Imagery and Mapping Agency (NIMA) is currently working on providing digitized charts and 
publications to the fleet user. Are there any requirements that you have which you would like to be included in 
NIMA’s efforts? 



3. Would you prefer to keep the current publication system for navigation planning, or would you prefer 
to have a new interactive “on-line” system developed? 



4. What type of Navigation Lessons Learned “library” (if any) does your command maintain now? 



5. What configuration would you prefer for a consolidated location or “library” of electronic Navigation information? 



Note: For question (6), please choose the degree of importance of each type of data from one of the following: 
1. Not Important 2. Somewhat Important 3. No Opinion/Neutral 4. Important 5. Essential 



6. If the following navigation related information sources were accessible in a single location, how important would 
they be to you? fPlease circle your choices ! 



1 2 3 4 5 
1 2 3 4 5 
1 2 3 4 5 

1 2 34 5 
1 2 34 5 
1 2 34 5 
1 2 34 5 
1 2 34 5 
1 2 34 5 
1 2 3 4 5 



Pictures of aids to navigation (range markers, towers, tanks, lights, etc.) 
Lessons Learned from other commands who have “gone before” 

Digitized navigation publications (Sailing Directions, Coast Pilot, 

List of Lights/Light List, Fleet Guides, etc.) 

Digitized charts and display 

Safety messages (HYDROPAC/LANT, NOTAMS) 

Overhead littoral imagery of navigation value 
Amphibious planning data (hydro surveys, assault plans, etc.) 

Historical exercise data (conops, clearance requirements, lead times, etc.) 
Meteorological data (tide/current predictions, prevailing conditions, etc.) 
Port data (pilotage, tugs, berth and port facilities, etc.) 



7. What navigation data or information sources would you add to a single, central navigation “library?” 



89 



8. I have used the Navy Tactical Information Compendium (OTIC) senes library and Navy Lessons Learned System 
as follows (please check all choices which apply): 

Purpose 
0 Exercise 
0 Transit 
0 Port Visit 
0 Amphib Ops 
0 Other 

9. On average, my command spends the following amount of time (in manhours) every week maintaining and 
correcting: 

Item Time spent maintaining 

0 HYDROPAC/LANT and Notam files 

0 Navigation Publications 

0 Charts 

0 Other 



10. In previous planning, what missing information did you need from other commands who had completed the 
same event? 



Frequency of Use 
0 Never 

0 Seldom (i.e. once/mo. or less) 

0 Regularly (i.e. once/wk. or more) 
0 Other 



11. I have used the following systems for navigation planning (check all that apply): 

0 GCCS 0 WWW 0 JDISS 0 Commercial Software 0 Other 

Title: 

12. If you have used a system from question (1 1 ) for navigation planning, for what purpose did you use it? 



13. In order to improve fleet feedback and to capture Navigation Lessons Learned, an improved method needs to be 
developed. Quantitative data (i.e. rating of tugs and pilot, navigation aid usefulness, etc.) as well as qualitative 
comments need to be collected. Please provide your thoughts on how this could best be accomplished. 



14. We are looking for ideas to improve fleet navigation planning, and we welcome your feedback. Please provide 
any comments or suggestions in the space below, and feel free to attach additional sheets if necessary. Thank you for 
your cooperation. 
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APPENDIX C. SURVEY DEMOGRAPHICS 



The following tables provide statistics on the number of respondents and their 
demographic makeup. 



General 


Surveys 


Population 


Percentage 


Information 


Received 


Size 


of Pop. 


Number of Total Respondents: 


238 






Number of Total Commands: 


159 


396 


40.2% 


Number of Ships: 


130 


333 


39.0% 


Number of Staffs: 


29 


63 


46.0% 


Lost Surveys 


1 






Misc/Unresolved 


1 






Ships by Type: CV/CVN 


6 


12 


50.0% 



CG/CGN 


12 


27 


44.4% 


DD/DDG 


21 


56 


37.5% 


FFG 


16 


42 


38.1% 


Total CRUDES 


49 


125 


39.2% 


SSN 


24 


68 


35.3% 


SSBN 


6 


18 


33.3% 


Total Subs 


30 


86 


34.9% 


LCC 


1 


2 


50.0% 


LHA 


3 


5 


60.0% 


LHD 


0 


5 


0.0% 


LPD 


2 


11 


18.2% 


LPH 


1 


1 


100.0% 


LSD 


5 


16 


31.3% 


LST 


1 


2 


50.0% 


Total Amphibs 


13 


42 


31.0% 



MCS 


0 


1 


0.0% 


MCM 


8 


14 


57.1% 


MHC 


2 


9 


22.2% 


Total Mine 


10 


24 


41.7% 



Warfare 
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PC 


5 


13 


38.5% 


AE 


2 


2 


100.0% 


AO 


2 


5 


40.0% 


T-AFS/AO/ATF 


4 


4 


100.0% 


AOE 


3 


7 


42.9% 


Total Logistics 


11 


18 


61.1% 


AS 


3 


4 


75.0% 


AGF 


1 


2 


50.0% 


AGSS 


1 


1 


100.0% 


ARS 


2 


4 


50.0% 


Total Aux Ships 


7 


11 


63.6% 


Total 


131 


331 


39.6% 



Staffs By Type 


Fleet 

CARGRU 

CRUDESGRU 

DESRON 

SUBGRU 

SUBRON 

PFUBRGRU 

PHffiRON 


2 5 

4 8 

2 6 

7 17 

5 5 

3 10 

0 3 

4 9 


40.0% 

50.0% 

33.3% 

41.2% 

100.0% 

30.0% 

0.0% 

44.4% 




Total 


27 63 


42.9% 


Months in Job 


Percent 


Rank 




>36 


26 10.9% 


>E-7 


37 


12 to 36 


103 43.3% 


<=E-6 


44 


< 12 


97 40.8% 


Second 


3 






Officer 




Not Specified 


12 5.0% 


O-l - 0-3 


113 


Total 


238 


0-4 


28 






05-0-6 


10 


Job Title 




Unknown 


3 


Navigators 


103 


Total 


238 


Asst. Navig. 


30 (Duplicates w/ Nav LCPOs) 




Staff Nav 


6 






CO 


2 






cso 


4 






xo 


13 







Operations Officer 3 1 
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OPS Jobs 
NAV LPO/LCPO 
OPS LPO/LCPO 

QMs 

Total 



14 (Asst. Ops, CICO, Amphib Ops, Staff Ops, Schedulers) 
20 
14 

7 

244 



Respondents by Job 




□ Navigators 

■ Asst. Navig. 

□ Staff Nav 

■ CO 
BCSO 

□ XO 

□ Operations Officer 
111 OPS Jobs 

H NAV LPO/LCPO 

□ OPS LPO/LCPO 

□ QMs 
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APPENDIX D. STATISTICAL CALCULATIONS FOR POPULATION MEAN 

CONFIDENCE INTERVALS 



The following calculations show values used to compute the confidence intervals 
depending on sample and population size. With only 13 respondents, the student’s “t” 
distribution was required for Amphibious results. The number of navigators responding 
was large enough to use standard normal distribution computations. 

The symbols used in the tables are: 

N= Observations 
0 = Sample mean 
O = Population mean . 

Sx = Sample standard deviation 
Z alpha/2 = Standard normal random variable 

t„-i = Random Variable from Student’s t distribution with (n-1) degrees of freedom 

Formula for calculating the Confidence interval for the Mean of a Normal Population, 
small sample size 



0 - (VO* S x / SQRT(N) < cp < 0 + (t n .,> S x / SQRT(N) 



Amphibious 




13 13 13 

4.29 4.29 4.29 

0.85 0.85 0.85 

95% 90% 80% 

2.179 1.782 ' 1.356 



Table value 



Pop Mean Range 
Low value 
High value 



3.78 3.87 3.97 

4.80 4,71 4.61 
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Confidence Interval for the Population Mean: Large Sample Sizes 

Note: When the sample size is large, the sample standard deviation will be a sufficiently 
good estimator of the population standard deviation to allow us to use the former in place 
of the latter without affecting the probability content of the intervals. 

0 - (Z alpha/2)*S x / SQRT(N) < < 0 + (Z alpha/2)* S x / SQRT(N) 



Navigators 



N 


103 


103 


103 


0 


4.19 


4.19 


4.19 


Sx 


0.71 


0.71 


0.71 


Z alpha/2 


99% 


95% 


90% 


Table Value 


2.57 


1.96 


1.65 


Low Value 


4.01 


4.05 


4.07 


High Value 


4.37 


4.33 


4.31 



AH 



N 


Responses 

238 


238 


238 


X Bar 


4.1 


4.1 


4.1 


Sx 


0.94 


0.94 


0.94 


Z alpha/2 


99% 


95% 


90% 


Table Value 


2.57 


1.96 


1.65 


Low Value 


3.94 


3.98 


4.00 


High Value 


4.26 


4.22 


4.20 
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APPENDIX E. NAVIGATION SURVEY RESULTS 



These are narrative responses to survey questions 2, 3, 5, 7, 10, and 14, received from 
July to October, 1997. Not all responses from all commands who participated in the 
survey are included here. Comments from commands who provided thorough responses 
which are useful to navigation planning are listed. Responses are paraphrased, and in 
some cases are directly quoted as indicated. 



USS SALVOR (ARS-52), Navigator 

• Need a Waypoint to Waypoint (voyage planning) calculator. 

• Good argument for “single source” Nav Repository in response #3 

• Include “Typhoon Havens” 

USS PRINCETON (CG-59), Navigator 

• Strong argument.for Pictures of Navaids! 

• Good argument for CD-Rom technology (updatable?) 

• Make digital charts vector charts (vice Raster) which are easily updated with 
commercial software. 

FFG, Navigator 

• “Put AAR File from DC into a database.” (FICM Port Visit Report) 

USS SIMPSON (FFG-56), Ops 

• “Make SURFLANT port-visit reports (FICM Format) available in a database!” 

• Include access to NGFS, Bottom Contour and Jog-Air Charts 

COMCARGRU TWO, Surface Ops Officer 

• Query port database by: 1) name, 2) lat/lon 

• Port-to-Port transit and time/distance figures 

USS TAYLOR (FFG-50), XO 

• “Investigate commercial nav software the Coast Guard uses.” 

• Include Traffic Patterns 

• Condition of piers and camel/fender capability 

• Foreign Port Tides 

COMSUBGRU TWENTY, Asst. Ops Officer 

• Include classified NOTAMs 

• Changes in Shoaling 

DESRON TWO, Navigator 
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• Distances between ports 

• Terrestrial (road/area) Maps of Arabian Gulf Ports to help determine usable 
Navaids 

• Pictures of Harbor 

USS KITTY HAWK (CV-63), Chief Quartermaster 

• “It would be great for all afloat units to have access to WWW to be able to 
access NAV info any time ” 

• “GPS Interfaceable” 

• Accepts NIMA’s digital charts” 

• “Depths at berths” 

USS DEXTROUS (MCM-13), XO/Navigator 

• Beach Topography 

• Bottom contours/type/gradient 

• Display ship size to scale 

• “On-line would save space on cramped MCM” 

USS ENTERPRISE (CVN-65), Navigator 

• ECDIS Planning Tool? 

• Accurate Port/ Anchorage charts for frequently visited foreign ports. 

USS L. MENDEL RIVERS (SSN-686), Nav/Ops 

• “Include foreign charts” (especially for ports) 

USS TORTUGA (LSD-46), Navigator 

• Standard Approach Tracks 

• Lights and Navaids with Pictures and Descriptions 

• Plot tracks, anchorages, boat lanes 

• Ability to calculate celestial data... movreps... trip planning 

• Coverage of “Hard to Reach” Areas 

USS CROMMELIN (FFG-37), Navigator 

• Include OPAREAS (as overlays) 

• Pier data, tug availability, BTB channel 

• Recommended pilot pick-up points 

USS O’BRIEN (DDG-975), Leading QM 

• Need Nav Dept. Hardware support! (PC, CD-ROM, modem, dedicated phone 
line, etc.) 
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USS PONCE (LPD-15), Navigator 

• “Bulletin Board” for on-line system 

LHA (Westcoast), Navigator 

• Include “British Recommended Route Book” 

USS COLUMBUS (SSN-762), Navigator 

• Visual LOPs into auto-updated position 

• Ability to “personalize” graphical display.... Navaids highlighted, Tug RDVU 
points, etc. 

USS COMSTOCK (LSD-45), Navigator 

• Develop a Cross-Reference System to enable ordering Foreign Charts 

• “Make it like JICPAC Home Page” 

USS SOUTH CAROLINA, Navigator 

• Use MOVREP for PVISIT Feedback 

• Disk/CD updates for non-Internet Commands 

USS SACRAMENTO (AOE-1), Asst. Navigator 

• NAVTREK 

• Digital Chart Display with GPS Interface 

• (DBMS) Query by Port 

USS KLAKRING (FFG-42), Navigator 

• Include “Safe Speed” along port transit legs 

• Pilot Pickup Points 

CRUDESGRU TWO, Navigator 

• Include Pictures of Navaids! 

• “Hot” Areas 

SUBRON ONE, Ops Officer 

• 3-D Charts for subs! 

COMCARGRU FIVE, Sub Ops 

• Vector Charts vice Raster 

• E-Series Sub Charts digitized by NIMA 

• GPS-ESGN 

• LAN accessible display 

• Select/Deselectable information; design Web Site with “filtering!” 
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USS CHIEF (MCM-14), Navigation Officer 

• MCM’s: not enough phone lines for NAVINFONET dump! 

• Add to PCO/PXO pipeline training on electronic NAV technology. 

COMDESRON FIVE, Navigator 

• WRN-6 Interface 

• Pierside Depths 

• Feedback form for ideas 

• Training/Documentation for new system 

USS GUNGSTON HALL (LSD-44), Navigator and Ops Officer 

• Forego Celestial Nav! (Nav) 

• Include Husbanding Agent e-mail address (Ops) 

CLF (AO), Navigator 

• Consolidate Nav transit/port visit feedback with MOVREP. 

USS MIAMI (SSN-755), Navigator 

• Include bottom contour charts 

• Traffic Density for Port Visits 

USS CLARK (FFG-11), LPO Nav. Dept. 

• “Storm Tracking” function 

USS SENTRY (MCM-3), ANAV (QMl(SW) Powell) 

• Great tool: Integrating GPS and Cap’n onboard. 

USS AUSTIN (LPD-4), ANAV 

• QMC memo to CNSL has documented need to upgrade Nav planning 
technology 

USS LOUISVILLE (SSN-724), Navigator 

• Produce “Chartlets” of OPAREAS (Cargru 7) 

• “JMCIS compatible” 

CVN, ANAV 

• Downloaded off of NIPRNET/SIPRNET 

• Include Port visit reports 

• Include Pictures of Navaids 

USS INDEPENDENCE (CV-62), LCPO 

• Include on Web site: “Advance/Transfer tables for ship class” 
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USS ARKANSAS (CGN-41), Navigator 

• Highlightable shoal water based on ship’s draft/input 

• Display current vectors real-time (direction and velocity) 

• Database of historical OTSR divert data 

• Generate Nav Aids expected to see based on intended track 

• Civilian/NOAA POC for improving NAV 

USS MONTPELIER (SSN-765), CO 

• Internet unavailable while submerged! 

• Digital charts and pubs would greatly ease sub stowage problem! 

AE, Navigator (West Coast) 

• Add Harbor “Common Approach” tracks 

CARGRUFOUR, Staff QM 

• Point and Click to get blown up Picture of Navaid! 

• Digitized charts/pubs would bring postage/shipping savings as a tangible 
benefit 

COMDESRON FIFTEEN, OSC 

• “Software to simplify ordering charts” (push/pull technology) 

• Time-Distance planning 

• “Fuel Bum Predictions” by ship class 

USS PHILIPPINE SEA (CG-58), Navigator 

• Query (i.e., Nav Areas, Hydrolants by Chart #) 

• Pilot pick-up pts, anchorages 

• Make feedback form a TYCOM directive 

USS STOUT (DDG-55), Navigator 

• SURFLANT Database (ports) available upon request via Code: CNSLN333 

USS PETERSON (DD-969), Navigator 

• Want “Pier” info: Depth at berth, pier specs, etc.! 

COMDESRON TWENTY SIX, Chief of Staff 

• “Danger Contours” 

• Bearings based on ship class 

• Status of lights/navaids: “Operational, light out...” 
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Need system compatible with PC CZ/VMS system 



PC, CO 

i 

USS AUBREY FITCH (FFG-34), LPO 

• Be able to change scale of chart (zoom in/out) 

• (NIMA Feedback) Need better scale charts for Panama Canal, etc. 

USS ROBERT G. BRADLEY (FFG-49), Navigator 

• “Standardize the names of Navaids, so that all USN ships called the available 
Navaids by the same name.” 

• “Found that many of the Navaids we thought would work didn’t.” 

USS TREPANG (SSN-674), Ops. 

• Put Navaid ID on charts so periscope operator can quickly and correctly 
identify Navaids. 

USS JAMES K. POLK (SSN-645), Navigator 

• See SUBPAC/LANT Inst. 5400 (Nav Operations Dept.) 

• CINCLANTFLEET and CINCUSNAVEUR maintain vast list of port visit 
reports 

• Include DOD 2005. 1M Maritime Claims Manual for pub digitization. 

USS CIMARRON (AO-177), Navigator 

• Digital Chart system should have onboard) “printing capability for portable use 
like for Boat Officers.” 

USS FIFE (DD-991), CO 

• Revive old USN “Mishaps at Sea” database/pub. 

USS HUE CITY (CG-66), Navigator 

• Anchorage Positions and bearings (visual aids). 

USS ZEPHYR (PC-8), Ops. 

• “We digitize our own charts” 

• Compatible with Sperry IBS System? 

USS TICONDEROGA (CG-47), XO/Nav. 

• Need to verify accuracy (and quality) of nav data in repository. 

• Data vulnerability concern. 

USS CALIFORNIA (CGN-36), Navigator 

• Pictures of Ports, Piers, Passages, and Straits 
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Description of Pier configuration 



COMDESRON SIX, Ops/Plans 

• “One-Stop-Shopping” 

• Pictures of Navaids 

• “Huge LAN w/ CD Jukebox” 

USNS SAN JOSE (T-AFS-7), Navigator 

• “Design (system/repository) so that merchants can voluntarily contribute 
feedback.” 

USS NICHOLAS (FFG-47), Asst. Navigator 

• Include Suez Canal Transit info. 

USS PAUL HAMILTON (DDG-60), CO 

• Pier depths 

• Pilot proficiency info., ex., years experience 

• DDG: “Digital pubs save space” 

• “Put pictures of navaids on the Web” 

SUBMARINE SQUADRON TWO, Deputy Commander 

• “Need adequate survey data for safe submerged operations in littoral shallow 
waters.” 

• “More local knowledge about direction and magnitude of current at various 
places along track.” 

DESTROYER SQUADRON SEVEN, CICO 

• “Include standard 4W grids in Opareas to alleviate confusion.” 

• “DGPS...is of sufficient accuracy/quality to be used for harbor transits instead 
of visual fixes.” 

• Include Code of Federal Regs (CFR) Panama Canal Transit information. 

<also: St. Lawrence Seaway and Locks, Kiel Canal/Locks, Suez Canal, etc > 

• Commands need to debrief Sea & Anchor details and capture the lessons 
learned. 

USS GUAM (LPH-9), Asst. Navigator 

• “USN should embrace the CAP’N program... current Instructions require us to 
operate in the Dark Ages!” 

USS FITZGERALD (DDG-62), CICO 

• Using Raytheon ECDISS 
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Have NIMA conduct an annual NAVIGATION PLANNING Symposium to 
brief improvements in services and products. 






USS JACKSONVILLE (SSN-699), Asst. Navigator 

• Pictures of Navaids 

SUBMARINE GROUP TWO, Ops. Officer 

• Navigation Planning is far behind current technology! 

USS SANTA FE (SSN-763), Nav/Ops 

• “(Nav Info) System would need to be integrateable into SNAP-III LAN” 

• Need up-to-date location info on Arabian Gulf and WESTPAC Oil Rig 
locations. 

• Location info. On special purpose Buoys such as Hawaiian “Fish Aggregating 
Device” (FAD) Buoys. 

USS PELELRJ (LHA-5), Navigator/ Asst. Navigator 

• “Centrally locating multiple sources of Nav. Info, by a geographical database 
would be a great help!” 

• Look at CJCS Instruction 6130.01 dtd 20May94 “ CJCS Master Navigation 
Plan ” 

• Do away with traditional visual fixing; use GPS exclusive fixing! 

USS POGY (SSN-647), Ops. /Nav. 

• Traffic Density and Patterns 

DESTROYER SQUADRON TWO, Chief of Staff 

• Use TOP SCENE for Nav Planning 

USS FRANK CABLE (AS-40), Nav/Ops 

• Include Traffic Density data. 

USS OHIO (SSBN-726), Navigator 

• Include “Downloadable” Power Point Nav. Briefs. 

AMPHIBIOUS SQUADRON SIX, Ops. 

• Collect repository of (landing) beach hydrographic surveys. 

• Mobile staffs would greatly benefit from digitized pubs and charts (Note: same 
reported by MCM’s, SSN’s, DDGs and FFGs)! 

SIXTH FLEET, Asst. Fleet Scheduler 

• Collect cost data with Port Visit Report per C6F prototype tool. 
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USS YORKTOWN (CG-48), CICO/Nav. 

• “SMART SHIP” Plan: Only maintain one set of charts. 

USS THE SULLIVANS (DDG-68), QM 

• More pictures of Navaids (a picture is worth a thousand words). 

• Pictures that show what the harbor looks like (NOAA Charts, do this with a 
few of those). 

• Digital Charts - “new Coast Guard Buoy Tenders in Newport showed me the 
Digital Chart System that fed into the control stations - it was great!” 

• Common pilot practices in different ports. 

USS BELLEAU WOOD (LHA-3), Navigator 

• Pictures of Harbor Approaches 

USS PATRIOT (MCM-7), QM 

• Recommended Port approaches 

• Digital Nav Pubs, i.e., sailing directions and Pub 151 

• “Put all Nav info, on a single, Worldwide network” 

• Include EEZ, political boundaries, buffer zones, etc. on digital charts. 

USS THORN (DD-988), Ops./Nav. 

• Scalable, editable (digital) charts where operator can superimpose tracks, 

OP AREAS, etc. 

USS JOHN F KENNEDY (CV-67), Navigator 

• “Raytheon ECDIS disks were corrupted” 

• Repository of feedback accessible through WWW 

• All pubs accessible through WWW 

USS FLETCHER (DD-992), Navigator 

• Store PowerPoint Nav Briefs 

• Need a “One-Stop Library” 

• “Scaling feature” for digital charts 

AMPHIBIOUS SQUADRON 11, CSO 

• Repository of Beach Surveys 

• Beach Imagery 

USS THACH (FFG-43), Navigator 

• Include merchant vessel feedback and lessons learned re: navigation. 
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SUBMARINE GROUP 7, ACOS/Ops 

• Make digital chart(s) “edgeless” so that you auto-shift to new chart. 

USS MOUNT HOOD (AE-29), Navigator 

• Include all (different) spellings for foreign ports. 

AMPHIBIOUS SQUADRON FIVE, SAC 

• E-mail feedback to a database. 

USS GEORGE WASHINGTON (CVN-73), Navigator 

• Have NIMA digitize OP AREA Charts and distribute via ECDIS 

• Add to Nav library: Airfields (Bingo fields). Sub transit lanes, traffic separation 
schemes, oil rig locations. 
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APPENDIX F. SURVEY QUESTION 6 GRAPHS 
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Graph F- 1 



Graph F- 2 



Number of Respondents 
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Graph F- 3 



Graph F- 4 
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Graph F- 5 



Graph F- 6 
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Graph F- 7 



Graph F- 8 
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Graph F- 9 



Graph F- 10 
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Graph F- 11 



QM Rating Average 22.0 4.26 4.19 4.36 4.07 4.29 3.44 3.16 3.79 4.60 4.67 

StdDev. 16.5 0.85 0.93 0.81 0.97 0.79 0.91 1.11 0.94 0.67 0.60 

Mode 36.0 4.00 4.00 5.00 5.00 5.00 3.00 3.00 4.00 5.00 5.00 
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>0-5 Average 10.9 4.00 4.40 4.00 4.30 4.20 3.78 2.70 3.30 4.30 4.50 

Std Dev. 5.6 1.25 0.70 0.67 0.82 1.40 1.30 1.34 0.82 0.95 0.53 

Mode 12.0 5.00 5.00 4.00 5.00 5.00 5.00 2.00 4.00 5.00 4.00 



PC/MCM/MHC Average 13.2 3.82 4.14 4.39 4.39 4.43 3.29 3.11 3.61 4.50 4.54 

StdDev. 5.3 1.06 0.76 0.88 0.83 0.63 0.85 1.10 0.99 0.64 0.69 

Mode 12.0 4.00 4.00 5.00 5.00 5.00 3.00 3.00 4.00 5.00 5.00 
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